Re: C23 thoughts and opinions

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.