> And I'd rather keep the library warning free instead of telling the users to switch warnings off.
Thank you! Separately, but related: fuck you, Google! (every time I have to deal with protobuf in C++, I curse Google and their "we don't give a shit about signed vs unsigned comparisons").
And I don't think there's an excuse not to. I work on giant projects with tons of people, that still manage to use -Werror.
Yeah, some warnings are turned off, but not as many as you'd think, and usually for good reasons, which also includes deliberate design decisions. For example, we don't care about pre-C11 compatibility (because we won't build for pre-C11), so that warning is off. We also like 0-sized arrays, so that warning is off as well.
It's a moving target, because compiler engineers add new warnings over time. Adapting the new compiler means taking care of the new warnings. There's almost always a way to do so instead of turning a new warning off.
The problem is: it's infectious into the generated code, as well. Is that 3rd party or not? Yes, it was generated by a 3rd party tool, but from, ostensibly, _your_ protobuf file.
edit to add: and yes `-isystem` is absolutely a useful tool. If memory serves, though, it doesn't protect from macro or template expansions, though.
Apparently the static_assert trick doesn't work with GCC, it just compiles it with a warning if it's not a constant expression:
warning: expression in static assertion is not an integer constant expression [-Wpedantic]
Instead you can use the sizeof + compound literal with array type, use the comma operator to preserve the type of the expression and cast the result of sizeof to void to suppress the warning:
This sort of thing is better set in CMake or equivalent with file specific flags to disable diagnostics. Then you don't have non-portable cruft littering the code, you don't have to touch third party code, and there is a more centralized accounting of what marginal code you're hacking around. The loss of specificity is rarely going to be a problem.
(this is from the standalone-no-libc-printf-family-implementation I maintain; the library is C, the test suite is C++ but it doesn't matter for the purposes of my point here.)
and that you only need to do once in your project (you can make it your own header). Even when it comes to use - you can place your warning-disabling within another macro, so that you end up only using a simple single macro for your actual code.
If you disable warnings in your makefile, you'll lose them for the entire C file. Pragma warnings as above allow them to be disabled for just the problematic code in question.
I use something similar in a container library to warn the user if he or she supplies an argument with potential side effects to a macro that evaluates it multiple times:
Specifically, if (arg)==(arg) is not a constant expression, then it could have side effects.
However, this mechanism does generate some annoying false positives, as shown below:
// Create a map with int keys and values that are vectors of floats:
map( int, vec( float ) ) our_map;
init( &our_map );
// Create a vector of floats:
vec( float ) our_vec;
init( &our_vec );
push( &our_vec, 1.23f );
// Insert the vector into the map.
insert( &our_map, 456, our_vec );
// Generates a warning because get checks its first argument for side
// effects and the compiler can't tell that the first argument of the
// outermost get has none:
printf( "%f", *get( get( &our_map, 456 ), 0 ) );
// The "proper", albeit cumbersome, way to achieve the same thing without a
// warning:
vec( float ) *itr = get( &our_map, 456 );
printf( "%f", *get( itr, 0 ) );
The use case that comes to mind is doing manual compile time optimization based on macro arguments. E.g. you have some assembly block that is fast but requires some immediate arguments, and you have a fallback path for the dynamic case, and you want to determine which one to call at compile time based on whether the arguments are constants or not.
I've seen something related, which returned a bool instead of failing compilation, be used to switch between a path the optimiser could inline and some assembly. You could probably use this to make sure it was always inlined.
If you're writing code that needs to behave deterministically and not have side effects, you could use this to make violations of determinism/side-effect-freeness fail fast, I guess?
It's great of programmers to aim for portability, but frankly it's kind of a stretch that an arbitrary C compiler that is limited in standard support would the same time be sophisticated enough to process these tricks as intended.
In my fork of chibicc (a small C11 compiler) there are plenty of additional logic that were implemented solely to play nice with C tricks from real world projects that could have been easier if they target later standards. The most recent being how curl's build script determines the size of primitive types: they use (sizeof(T) == N) as a case index and expect the compiler to error on case-duplication[1], I had to add a backtracking loop to check exactly that[2]. I'm not complaining as more error checks isn't a bad thing, however, I'll advise programmers willing to invest in obscure tricks to actually test them on obscure compilers (instead of just flipping -std).
If the goal of testing on obscure compilers is to enhance such compilers then I'm all for it.
But I don't see much value in having to dance around implementation details to support a compiler which isn't standards compliant. Ideally standards conforming code should just work, that's the point of conforming to a standard.
Depends if you want people to be able to use your library with those compilers or not. If it's free software, fine. Don't fire well-paying customers though.
curl is one of those projects that's probably meant to be ultra-portable, though, working across an incredibly wide range of platforms, some probably with comparably ancient compilers.
I don't actually know any details so I don't want to presume, but it wouldn't surprise me at all if targeting later standards simply isn't an option for the curl project due to portability. It may be that the (sizeof(t) == n) trick may just be what consistently works across all targets. (Until yours came along.)
I do remember when configure etc. still had to check whether ANSI prototypes (as opposed to the original K&R style declarations) were supported... I hope that check isn't much of a thing anymore.
Semi-related: given an expression which is an integer constant, convert it to a statically-allocated char array. With appropriate sigils this can be extracted via `strings(1)`, even when cross-compiling.
If you don't know what type of integer your preprocessor is using for arithmetic, you can still do right-shifts by up to 14 at a time, since `int` must be at least 16 bits and you can't use the sign bit.
Readit News
Thank you! Separately, but related: fuck you, Google! (every time I have to deal with protobuf in C++, I curse Google and their "we don't give a shit about signed vs unsigned comparisons").
Yeah, some warnings are turned off, but not as many as you'd think, and usually for good reasons, which also includes deliberate design decisions. For example, we don't care about pre-C11 compatibility (because we won't build for pre-C11), so that warning is off. We also like 0-sized arrays, so that warning is off as well.
It's a moving target, because compiler engineers add new warnings over time. Adapting the new compiler means taking care of the new warnings. There's almost always a way to do so instead of turning a new warning off.
edit to add: and yes `-isystem` is absolutely a useful tool. If memory serves, though, it doesn't protect from macro or template expansions, though.
Why not push/pop warnings to ignore in the library?
But you don't want to disable warnings throughout the file, just locally.
> Then you don't have non-portable cruft littering the code,
You can make it perfectly portable, with a little macro work. See, ,for example:
https://github.com/eyalroz/printf/blob/013db1e345cbb166a7eb7...
(this is from the standalone-no-libc-printf-family-implementation I maintain; the library is C, the test suite is C++ but it doesn't matter for the purposes of my point here.)
and that you only need to do once in your project (you can make it your own header). Even when it comes to use - you can place your warning-disabling within another macro, so that you end up only using a simple single macro for your actual code.
* Some versions can only change compiler options at top level, not within a function.
* I had problems with trying to push/ignore/pop a warning around an expression in a macro, since the entire thing expands at a single location.
https://github.com/JacksonAllan/CC/blob/42a7d810274a698dff87...
Specifically, if (arg)==(arg) is not a constant expression, then it could have side effects.
However, this mechanism does generate some annoying false positives, as shown below:
In my fork of chibicc (a small C11 compiler) there are plenty of additional logic that were implemented solely to play nice with C tricks from real world projects that could have been easier if they target later standards. The most recent being how curl's build script determines the size of primitive types: they use (sizeof(T) == N) as a case index and expect the compiler to error on case-duplication[1], I had to add a backtracking loop to check exactly that[2]. I'm not complaining as more error checks isn't a bad thing, however, I'll advise programmers willing to invest in obscure tricks to actually test them on obscure compilers (instead of just flipping -std).
[1]: https://github.com/curl/curl/blob/339464432555b9bd71a5e4a4c4...
[2]: https://github.com/fuhsnn/slimcc/blob/54563ecae8480f836a0bb2...
I don't actually know any details so I don't want to presume, but it wouldn't surprise me at all if targeting later standards simply isn't an option for the curl project due to portability. It may be that the (sizeof(t) == n) trick may just be what consistently works across all targets. (Until yours came along.)
I do remember when configure etc. still had to check whether ANSI prototypes (as opposed to the original K&R style declarations) were supported... I hope that check isn't much of a thing anymore.
If you don't know what type of integer your preprocessor is using for arithmetic, you can still do right-shifts by up to 14 at a time, since `int` must be at least 16 bits and you can't use the sign bit.
Deleted Comment