Required to enable level 3 warnings. See: #1113 (review).
In addition, this PR enables MSVC warning C4334 for the entire codebase.
Required to enable level 3 warnings. See: #1113 (review).
In addition, this PR enables MSVC warning C4334 for the entire codebase.
Hm, weak concept NACK.
I’m not convinced that it’s worth complicating our source code or spending the time to optimize for MSVC warnings. MSVC warnings are very strange. And warnings are mostly useful for devs. No regular contributors here use MSVC currently, and I don’t expect any future contributors to use MSVC a lot. gcc is so much better even on Windows.
I’d also be fine with what you suggested in the initial CMake PR:
0 try_add_compile_option(/W3)
1 try_add_compile_option(/wd4146)
2 try_add_compile_option(/wd4244)
3 try_add_compile_option(/wd4267)
4 try_add_compile_option(/wd4334)
Adding these just documents the reality on MSVC, but we don’t need to touch our code base. I’m ~0 on #1293. That one could be reasonable because then we have a clean /W2 at least.
I’m not convinced that it’s worth complicating our source code or spending the time to optimize for MSVC warnings.
Agree with this entirely, and we’ve pushed back against these kind of “refactor perfectly working code, for the sake of Windows (warnings)” changes in the Core repository.
I’m not convinced that it’s worth complicating our source code or spending the time to optimize for MSVC warnings.
I agree with this statement, in general. This change, i.e., s/1
/1ULL
/ does not look like “complicating our source code” at all :)
we’ve pushed back against these kind of “refactor perfectly working code, for the sake of Windows (warnings)” changes in the Core repository.
I strongly disagree with neglecting Windows as a build platform. Diversity is essential for surviving. And diversity of well supported platform for Bitcoin Core is essential in long run (assuming you can’t see the future).
Anyway, feel free to close this PR.
682@@ -683,7 +683,7 @@ static int secp256k1_ecmult_pippenger_batch(const secp256k1_callback* error_call
683 }
684 state_space->ps = (struct secp256k1_pippenger_point_state *) secp256k1_scratch_alloc(error_callback, scratch, entries * sizeof(*state_space->ps));
685 state_space->wnaf_na = (int *) secp256k1_scratch_alloc(error_callback, scratch, entries*(WNAF_SIZE(bucket_window+1)) * sizeof(int));
686- buckets = (secp256k1_gej *) secp256k1_scratch_alloc(error_callback, scratch, (1<<bucket_window) * sizeof(*buckets));
687+ buckets = (secp256k1_gej *) secp256k1_scratch_alloc(error_callback, scratch, (1ULL << bucket_window) * sizeof(*buckets));
0 buckets = (secp256k1_gej *) secp256k1_scratch_alloc(error_callback, scratch, ((size_t)1 << bucket_window) * sizeof(*buckets));
size_t
is the correct type here
206@@ -207,6 +207,7 @@ include(TryAppendCFlags)
207 if(MSVC)
208 # Keep the following commands ordered lexicographically.
209 try_append_c_flags(/W2) # Moderate warning level.
210+ try_append_c_flags(/w24334) # Enable warning C4334 "result of 32-bit shift implicitly converted to 64 bits" as a level 2 one.
I don’t think we should try to enable more warnings here manually.
We may want to go with /W3 (with some explicitly disabled) but this could be part of another PR then, though I’m not entirely if I would to support that change. MSVC is very picky about some things, and we may run into other false positives in the future, requiring us to make more changes etc.
I’m not convinced that it’s worth complicating our source code or spending the time to optimize for MSVC warnings.
I agree with this statement, in general. This change, i.e., s/
1
/1ULL
/ does not look like “complicating our source code” at all :)
Ok, you’re perfectly right here, of course. I think I rather meant “Concept NACK on complicating our source to make MSVC happy”. But that comment is a bit superficial for this PR, which I think indeed actually improves the source code, independently of whether it makes a warning go away.
I strongly disagree with neglecting Windows as a build platform. Diversity is essential for surviving. And diversity of well supported platform for Bitcoin Core is essential in long run (assuming you can’t see the future).
I don’t think we’re neglecting it as a build platform. It’s rather deprioritizing it a bit as a dev platform, and then it’s a question of the right balance. I think we should not overdo it. Compiler warnings are useful in general, but making multiple compilers happy at the same time is difficult. (And anyway, I don’t think disabling warnings on the command line options instead of changing source means neglecting a platform.)
This change fixes MSVC level-3 warning C4334.
See: https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4334
Required to enable level 3 warnings (/W3).