Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Thu, 23 May 2024 15:02:26 +0300
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <20240523150226.00007e7d@yahoo.com>
References: <v2l828$18v7f$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 May 2024 14:02:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="65285ad7961782d3c0ffb469858810a7";
	logging-data="1819128"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18dSDGKC/6IDtuDrDNJStkZ38wbI5Apf6k="
Cancel-Lock: sha1:TWR0OhP2jH++TJTNRFNVvh9QWHs=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4549

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
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
3) IDNC
4) IDNC
5) IDNC
6) IDNC
7) bad. Breaks existing code for weak reason
8) bad. Breaks existing code for weak reason


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 

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().

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.