> 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.
I don't understand this discussion. What I said was that for our big projects internally, we keep them warning-free, and -Werror obviously helps tremendously with that. Nobody said you need to ship externally with -Werror, or anything about external libraries the project may be using.
By keeping your own project warning-free in your environment, you are doing a service to everyone.
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.
Uh, you are right. C is the right name. It throws.
I mixed it up with a similar compile-time constness check in some of my libraries, where I decided if const of not. gcc throws, only clang could give me a proper answer.
gcc will not let you actually define a negatively-sized array. Check it with some simple code -- I did. Even with -Wall -Wextra -O1 -std=c11 -Wpedantic, if I actually try to create foo[-1], on the stack or in BSS, I get the proper error:
error: size of array 'foo' is negative
This takes me back - all those compiler hacks just to keep stuff portable kinda drive me nuts tbh. I love seeing people push for warning-free code, though.
This is not for declaring constexpr variables, it is about how to implement a checker function that verifies an inline expression is constant. Plus some of the examples work back to C99 instead of C23, which I would wager close to zero people are using in real-world code bases.
You'd probably still win the wager but I do want to say there are some of us using C23. We even use it in our embedded systems running on arm based microcontrollers. Though we still do maintain some C89 code :(
The article mentions C23, but what they're trying to do is detect if something (possibly declared by someone else?) is a compile time constant, not to declare it as such
> And this cannot be silenced with #pragma since it's a macro, so the warning occurs at the location where the macro is invoked.
I seem to remember there's actually a solution for this .. at least on clang and I think MSVC .. you can programmatically turn warnings on/on with the _Pragma() macro. I don't remember exactly what you put in it, but it's designed specifically for this kind of macro nonsense
> 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 person who writes the library isn't using the same compiler as you.
True, so?
So turn on -Werror in your CI builds, but don't turn it on for all builds.
I mean, yeah, obviously that a)only works when we build our projects ourselves, and b) for external libraries you have less control over that.
Fuck projects that ship conpile scripts with -Werror.
I don't understand this discussion. What I said was that for our big projects internally, we keep them warning-free, and -Werror obviously helps tremendously with that. Nobody said you need to ship externally with -Werror, or anything about external libraries the project may be using.
By keeping your own project warning-free in your environment, you are doing a service to everyone.
I just turn warnings off for protobuf stuff. In general I do that for any code I don't own but have to compile.
3rdparty libs should be treated as -isystem. Otherwise you're just needlessly paying for other's mistakes.
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:
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: The only problem is that it doesn't support floating point expressions>And I'd rather keep the library warning free instead of telling the users to switch warnings off.
Why not push/pop warnings to ignore in the library?
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.
> with file specific flags
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.
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.
This probably isn't relevant anymore, but for now-old (4.x I think) versions of GCC, there are a couple of caveats:
* 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.
__builtin_choose_expr can be used instead of a ternary to avoid the type conversion rules that require the typeof cast
Is there a use case for such a macro, or is it just a puzzle for its own sake?
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:
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:
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?
Probably not. The Linux kernel has one.
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).
[1]: https://github.com/curl/curl/blob/339464432555b9bd71a5e4a4c4...
[2]: https://github.com/fuhsnn/slimcc/blob/54563ecae8480f836a0bb2...
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.
The macro should be called IS_CONST(), not C()
I agree, but for a blog post it is more concise (IS_CONST or anything that is long would take up a lot more screen real estate on my phone).
To determine if an expression is constant in C, one must determine if an expression in C is constant.
Would you expect IS_CONST to evaluate to the constant? With a name like that I would expect it to evaluate to true/false.
C here is asserting that the value inside is a constant and then evaluating to that constant.
Uh, you are right. C is the right name. It throws.
I mixed it up with a similar compile-time constness check in some of my libraries, where I decided if const of not. gcc throws, only clang could give me a proper answer.
gcc will not let you actually define a negatively-sized array. Check it with some simple code -- I did. Even with -Wall -Wextra -O1 -std=c11 -Wpedantic, if I actually try to create foo[-1], on the stack or in BSS, I get the proper error: error: size of array 'foo' is negative
This takes me back - all those compiler hacks just to keep stuff portable kinda drive me nuts tbh. I love seeing people push for warning-free code, though.
Meanwhile in C++ land, use if consteval, unless not able to use recent standards.
One can use _Pragma inside macros
If C23 is why not use constexpr?
https://en.cppreference.com/w/c/language/constexpr
This is not for declaring constexpr variables, it is about how to implement a checker function that verifies an inline expression is constant. Plus some of the examples work back to C99 instead of C23, which I would wager close to zero people are using in real-world code bases.
You'd probably still win the wager but I do want to say there are some of us using C23. We even use it in our embedded systems running on arm based microcontrollers. Though we still do maintain some C89 code :(
C23 on embedded ARM is entirely painless as it’s all upstream GCC these days anyway.
The problem is if you want to also still support esp8266 which is forever stuck at GCC 8.4
The article mentions C23, but what they're trying to do is detect if something (possibly declared by someone else?) is a compile time constant, not to declare it as such
> And this cannot be silenced with #pragma since it's a macro, so the warning occurs at the location where the macro is invoked.
I seem to remember there's actually a solution for this .. at least on clang and I think MSVC .. you can programmatically turn warnings on/on with the _Pragma() macro. I don't remember exactly what you put in it, but it's designed specifically for this kind of macro nonsense
[dead]