Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Sun, 26 May 2024 16:15:41 +0200
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <v2vg6e$3eaba$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me> <20240523150226.00007e7d@yahoo.com>
 <87a5kg5voc.fsf@nosuchdomain.example.com> <v2qal7$2c8rq$3@dont-email.me>
 <87fru72elx.fsf@nosuchdomain.example.com> <v2si1s$2rle2$4@dont-email.me>
 <87ed9p1nry.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 26 May 2024 16:15:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="75f63f5864dc091ec43360d736bfcccd";
	logging-data="3615082"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/8tQX89nmMX5TAwaKg9TVHBGIcgMz3xBg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Wes5TPCcna4X49hzc01dRdfV1oQ=
Content-Language: en-GB
In-Reply-To: <87ed9p1nry.fsf@nosuchdomain.example.com>
Bytes: 3606

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.