Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.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: Sat, 25 May 2024 13:29:00 +0200
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <v2si1s$2rle2$4@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 25 May 2024 13:29:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5acf865375c1c1cdc2a566d884dbbc5b";
	logging-data="3003842"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19HD3nTsFCwOuv9K04lKhDsMrZDc6KoGcM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:RxP1EFdxswvZH2MVhEJcRxvRMuA=
Content-Language: en-GB
In-Reply-To: <87fru72elx.fsf@nosuchdomain.example.com>
Bytes: 4164

On 24/05/2024 21:29, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 23/05/2024 18:40, Keith Thompson wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
>>> [...]
>>>> Removed
>>> [...]
>>>> 7) static_assert is not provided as a macro defined in <assert.h>
>>>> (becomes a keyword)
>>>> 8) thread_local is not provided as a macro defined in <threads.h>
>>>> (becomes a keyword)
>>>>
>>> [...]
>>>> 7) bad. Breaks existing code for weak reason
>>>> 8) bad. Breaks existing code for weak reason
>>> In pre-C23, _Static_assert and _Thread_local are keywords, and
>>> static_assert and thread_local are macros that expand to those keywords.
>>> In C23, _Static_assert, _Thread_local, static_assert, and
>>> thread_local
>>> are all keywords.  Code that simply uses the old ugly keywords would not
>>> break.
>>> Code that does something like "#ifdef static_assert".  I suppose the
>>> headers could have retained the old macro definitions.
>>>       #define static_assert static_assert
>>>       #define thread_local thread_local
>>>
>>
>> The sort of code that could theoretically break is when you have
>> definitions like this:
>>
>> #define STATIC_ASSERT_NAME_(line)       STATIC_ASSERT_NAME2_(line)
>> #define STATIC_ASSERT_NAME2_(line)      assertion_failed_at_line_##line
>> #define static_assert(claim, warning) \
>>      typedef struct { \
>>          char STATIC_ASSERT_NAME_(__COUNTER__) [(claim) ? 2 : -2]; \
>>      } STATIC_ASSERT_NAME_(__COUNTER__)
>>
>> That works in any C version, until C23, almost as well as
>> _static_assert.  I used this when C11 support was rare in the tools I
>> used.
> 
> You mean _Static_assert.

I meant either "static_assert" or "_Static_assert", rather than a 
mixture of the two!  (I consider "static_assert" part of C11 even though 
it needs a header.)

> 
>> While using #define for a C keyword is undefined behaviour, in
>> practice I think you'd have a hard time finding code and a compiler
>> that used such a macro and which did not work just as well in C23
>> mode.
>>
>> (I don't know if anyone is in the habit of declaring macros named
>> "thread_local".)
> 
> "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.

> You can fix it by
> adding "#undef static_assert" or by picking a different name, or by
> making your macro definition conditional on __STDC_VERSION__ >= 202311L.
> 

The actual code I use had a number of conditional checks for different C 
standards and C++, so that it does not define a static_assert macro for 
C++ (my C++ usage for the code was always at least C++11), and for C11 
onwards it was defined to _Static_assert.  (I specifically did not want 
to include <assert.h>.)