Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB-Alt <bohannonindustriesllc@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Thu, 23 May 2024 17:15:44 -0500
Organization: A noiseless patient Spider
Lines: 153
Message-ID: <v2of6i$1uvnr$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me> <20240523150226.00007e7d@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 May 2024 00:15:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7c498ee9c2f8f4fbbd41c47e63b2cc4b";
	logging-data="2064123"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19yvFNWwDB/qKjKUni7nfLFIr/P0y8V9tI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:72AcJxW9wcIoEbMHPMqtl2hoPrA=
Content-Language: en-US
In-Reply-To: <20240523150226.00007e7d@yahoo.com>
Bytes: 6568

On 5/23/2024 7:02 AM, Michael S wrote:
> On Wed, 22 May 2024 18:55:36 +0200
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> In an attempt to bring some topicality to the group, has anyone
>> started using, or considering, C23 ?  There's quite a lot of change
>> in it, especially compared to the minor changes in C17.
>>
>> <https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf>
>> <https://en.wikipedia.org/wiki/C23_(C_standard_revision)>
>> <https://en.cppreference.com/w/c/23>
>>
>> I like that it tidies up a lot of old stuff - it is neater to have
>> things like "bool", "static_assert", etc., as part of the language
>> rather than needing a half-dozen includes for such basic stuff.
>>
>> I like that it standardises a several useful extensions that have
>> been in gcc and clang (and possibly other compilers) for many years.
>>
>> I'm not sure it will make a big difference to my own programming -
>> when I want "typeof" or "chk_add()", I already use them in gcc.  But
>> for people restricted to standard C, there's more new to enjoy.  And
>> I prefer to use standard syntax when possible.
>>
>> "constexpr" is something I think I will find helpful, in at least
>> some circumstances.
>>
> 
> 
> Removed
> 1) Old-style function declarations and definitions
> 2) Representations for signed integers other than two's complement
> 3) Permission that u/U-prefixed character constants and string
> literals may be not UTF-16/32
> 4) Mixed wide string literal concatenation
> 5) Support for calling realloc() with zero size (the behavior becomes
> undefined) 6) __alignof_is_defined and  __alignas_is_defined
> 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)
> 
> 1) good

I am mixed on 1, while I don't write any code using it, I am still using 
some code that uses them (and requiring, say, modifying the Dhrystone 
benchmark because it was using K&R style C, seems a bit weak).


> 2) good, but insufficient. The next logical step is to make both left
> and right shift of negative integers by count that does not exceed #
> of bits in respective type fully defined

Agreed. I might go further, but either way.


Though, I have found that there is wonk in a few cases, like some code 
expecting that variable shifts are Mod N, while also expecting that 
constant shifts are non-modulo (and that negative shifts will shift in 
the opposite direction).

Granted, better for code to *not* rely on the behavior of out-of-range 
or negative shifts, but alas...


May not matter that much (IIRC, when porting code like this to GCC, it 
will give an error about the out-of-range shifts). Granted, in some ways 
GCC was less conservative.

Though, the same program had also relied on the ability to use 
out-of-bounds access to global arrays to access things inside other 
global arrays (this broke in my initial porting attempt, as my compiler 
does not preserve the relative order or alignment of global variables; 
IOW: the C toplevel is not a struct...).


> 3) IDNC
> 4) IDNC
> 5) IDNC
> 6) IDNC

> 7) bad. Breaks existing code for weak reason
> 8) bad. Breaks existing code for weak reason

Agreed, would probably keep them as #define's.

One general thing of mine is, despite adding some amount of language 
extensions in my own compiler, not changing things that breaks existing 
code.

> 
> Deprecated
> 1) <stdnoreturn.h>
> 2) Old feature-test macros
>    __STDC_IEC_559__
>    __STDC_IEC_559_COMPLEX__
> 3) _Noreturn function specifier
> 4) _Noreturn attribute token
> 5) asctime()
> 6) ctime()
> 7) DECIMAL_DIG (use the appropriate type-specific macro
>      (FLT_DECIMAL_DIG, etc) instead)
> 8) Definition of following numeric limit macros in <math.h> (they
> should be used via <float.h>)
>    INFINITY
>    DEC_INFINITY
>    NAN
>    DEC_NAN
> 9) __bool_true_false_are_defined
> 

3 and 4. Mixed, would mostly only effect library headers so probably OK.


> No opinion on most of those.
> W.r.t. 5 and 6.
> IMHO, all old-UNIX-style APIs that return pointers to static
> objects within library or rely on presence of static object within
> library for purpose of preserving state for subsequent calls should be
> systematically deprecated and for majority of them there should be
> provided thread-safe alternatives akin to ctime_s().
> That is, with exception of family of functions that uses FILE*. Not
> that I like them very much, but they are ingrained too deeply.
> So, peeking just asctime and ctime out of long list of  problematic
> APIs does not appear particularly consistent. If they were asking me
> where to start, I'd start with rand().
> 

I ended up turning "errno" into thread-local state in my implementation 
with no real ill effect.

This mostly leaves the "locale" stuff as global state (in my case, the 
locale mostly effects whether to interpret some things as UTF-8 or 1252 
/ 8859-1, if it can't be figured out in other ways).


> With regard to new feature, the list is too long to comment in one post.
> Just want to say that strfrom* family is long overdue, but still appear
> incomplete. The guiding principle should be that all format specifiers
> available in printf() with sole exception of %s should be provided as
> strfrom* as well.
> 

Not much opinion here.

> 
> 
> 
> 
> 
> 
> 
>