Resolve warnings in VC-WIN32 build, which allows to add /WX. #4721
Conversation
|flags| argument to do_esc_char was apparently truncated by implicit cast. [Caught by VC warning subsytem.]
Even though |Blen| is declared uint64_t it was casted implicitly to int. [Caught by VC warning subsytem.]
…dd /WX. It's argued that /WX allows to keep better focus on new code, which motivates its comeback... [Keep this commit separate as reminder for time overhaul.]
It's argued that /WX allows to keep better focus on new code, which motivates its comeback...
We had /WX (treat warnings as errors) in VC-WIN32 for long time. At some point it was somehow omitted. It's argued that it allows to keep better focus on new code, which motivates the comeback...
test/asn1_time_test.c
Outdated
| /* ASSUMES SIGNED TIME_T */ | ||
| static struct testdata tbl_testdata_neg[] = { | ||
| { "19011213204552Z", V_ASN1_GENERALIZEDTIME, V_ASN1_GENERALIZEDTIME, 1, -2147483648, -1, 0, }, | ||
| { "19011213204552Z", V_ASN1_GENERALIZEDTIME, V_ASN1_GENERALIZEDTIME, 1, (time_t)-1*2147483648, -1, 0, }, |
There was a problem hiding this comment.
Is this done like this to avoid overflow? Space around the multiplier operation. Perhaps a comment explaining why it's written like this?
There was a problem hiding this comment.
Yeah, about that... Problem there is that compiler complains with "unary minus operator applied to unsigned type, result still unsigned". But target type is actually signed, and from standard's point of view unsigned to signed is implementation-specific, which in turn something we would like to avoid. Hence the trouble. One can probably argue that it's kind of a compiler bug, because -123 can be viewed not as unsigned with unary minus, but as negative number to start with. But now after extra consideration I've found alternative, less controversial way to solve it.
[As curious fact, INT_MIN is customarily defined as -2147483647-1, so that compiler in question doesn't complain, because 2147483647 doesn't have most significant bit set.]
|
There were warnings that needed to be addressed... Give CIs a chance... |
|
Will there be something similar for 64-bit? |
|
As for tavis failure. I don't quite follow. Originally it was what I think is a transient failure [in 70-test_sslrecords], but now it's complaining about doc-nits... Anyway, neither is relevant... |
I don't follow. Similar what? There are tests for 64-bit time_t, both positive and negative. Those are tests that got explicit casts to (time_t) in very last commit. Though casts are there to shut up compiler in cases when time_t is 32 bits. If you sense contradiction, you should recognize that 64-bit tests are guarded with |
Oh! You probably mean /WX for VC-WIN64, right? Sorry, I was in context of test/asn1_time_test.c.... |
Yes, exactly. Sorry for being unclear |
It should be a goal, but as it stands now it's too much work, that is it's not something that can be done "just like that". And "too much work" doesn't mean "too many places to add explicit cast". I for one would argue that massive mechanical casts' addition to resolve warnings would actually do more harm than good. This is because they should be considered in their contexts and resolved rather on per-case basis. There might be bugs/quirks hiding there. And this request actually confirms this, as two first commits kind of work around subtle quirks/bugs. |
Forgot to clarify that there is nothing magic about WIN64 target, other 64-bit compilers actually could issue similar/corresponding warnings. It just so happens that VC is the only one[?] that does. |
|
Looking at time line it appears that last re-approval was after last commit, so it's formally approved. But to be on safe side(*) I'd like to see another re-approval. Rich? (*) I feel that there a chance that very last commit could not considered, as it was added practically same moment. |
Considering VC is what we currently support (in the default Windows environment, i.e. not mingw / Cygwin), I don't see why we should care about other compilers. So yeah, my target is VC-WIN64. |
I don't follow. What I'm saying is that warnings reported by VC-WIN64 are not exactly WIN64-specific. Or in other words they are meaningful to address on all platforms. As already mentioned, for example two first commits in this request do address pair of concerns and they are not least Windows specific, not even specific to 64-bit platforms. It's not about caring for specific compiler, but for our code itself... |
|
I'm thinking that there may be a certain overlap for certain types of errors / warnings that are Windows specific, sure. But there may also be a portion of errors / warnings that happen to be specific to VC-WIN32, and perhaps some others that may be specific to VC-WIN64. By having /WX on VC-WIN32 only may mean we "miss" the latter, and raises the question why we should be more stringent with VC-WIN32 than with VC-WIN64. As a comparison, we allow --strict-warnings on both linux-x86 and linux-x86_64 ;-) (another thought that occured to me now is that adding /WX the way you do is making it constant... as compared to Unix systems where we only add -Werror if --strict-warnings is given... is that intentional?) |
|
("Unix systems" is incorrect, it should say "gcc or derivative" as compared to VC) |
And the answer is, as already mentioned, /WX in VC-WIN64 is not currently feasible. That's all.
One can as well flip the question and ask why not make --strict-warnings default [for gcc and clang]. After all we do insist on addressing those warnings before committing by exercising them through CI. Answer to that question is that we don't want to make such specific assumption about target environment [other than CI]. And if we don't, then we are better off with it being an opt-in option. As practical example, you can't use --strict-warnings with gcc 3.x, or under MacOS X. On the other hand VC-WIN* targets are rather homogeneous and making such assumption has fair chance to actually work. And it does with VC-WIN32... |
|
reconfirm. +1 |
|flags| argument to do_esc_char was apparently truncated by implicit cast. [Caught by VC warning subsytem.] Reviewed-by: Rich Salz <[email protected]> (Merged from #4721)
Even though |Blen| is declared uint64_t it was casted implicitly to int. [Caught by VC warning subsytem.] Reviewed-by: Rich Salz <[email protected]> (Merged from #4721)
…dd /WX. It's argued that /WX allows to keep better focus on new code, which motivates its comeback... [Keep this commit separate as reminder for time overhaul.] Reviewed-by: Rich Salz <[email protected]> (Merged from #4721)
It's argued that /WX allows to keep better focus on new code, which motivates its comeback... Reviewed-by: Rich Salz <[email protected]> (Merged from #4721)
We had /WX (treat warnings as errors) in VC-WIN32 for long time. At some point it was somehow omitted. It's argued that it allows to keep better focus on new code, which motivates the comeback... Reviewed-by: Rich Salz <[email protected]> (Merged from #4721)
|
One the commits meant for 1.1.0 didn't cherry-pick, because file was renamed. Closing this. |
|flags| argument to do_esc_char was apparently truncated by implicit cast. [Caught by VC warning subsytem.] Reviewed-by: Rich Salz <[email protected]> (Merged from #4721) (cherry picked from commit 3724631)
[Two first commits should go to 1.1.0. That's why it's labeled
masterand1.1.0.]