Re: C23 thoughts and opinions

On 26/05/2024 01:21, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 24/05/2024 21:29, Keith Thompson wrote:

[...]

"static_assert" is already a macro defined in <assert.h> starting in
C11.  The above code is valid in pre-C23, but will break in C11 and C17
if it includes <assert.h> directly or indirectly.

>
Yes.  But including <assert.h> is optional.

 Your header that defines your own "static_assert" macro might depend on
some other header outside your control.  A future version of that other
header might add a "#include <assert.h>", breaking your code.
 

I believe - but am not entirely sure - that the standard library headers are not allowed to include each other, precisely so that there will not be conflicts between user-defined identifiers and standard library identifiers from headers that you did not explicitly include.
I appreciate what you are saying, and it can often make sense for other people.  But in /my/ code, there is no possibility of future versions of headers having other includes.  In my projects, I consider the entire toolchain to be part of the project, along with any other libraries or SDK's.  Surprises like that don't happen when I am working on a project - nor when I take the same project out of archives and rebuild it 20 years later to get exactly the same binary, nor when anyone else does that.  Reproducible builds are vital to my work.
Of course, if I re-use the same code in a different project with different toolchains or libraries, such issues could crop up - but they are easily spotted and handled at the time.

There are solutions (check "#ifdef static_assert" for the macro and
__STDC_VERSION__ for the keyword, etc.)
 

Indeed.

Perhaps it's not an issue for you, but it's a corner case to keep in
mind.
 

It is not an issue for me, no - but I agree that it can be an issue for some people, and I agree it is worth keeping in mind.  I am not suggesting that defining your own static_assert macro is a good idea for general use - I was merely saying that /I/ had used it as a temporary measure before C11 (and C++11) became practical for the majority of work I did, and that it could have compatibility issues when moving to C23.