Re: C23 thoughts and opinions

On 23/05/2024 14:02, 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

Yes, at long last.

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.

3) IDNC
4) IDNC
5) IDNC
6) IDNC
7) bad. Breaks existing code for weak reason
8) bad. Breaks existing code for weak reason
 

I am of the opinion that people should specify the standard they use as part of their build procedures.  (I'd have liked a standard way to specify the C standard version code uses, so that it could be fixed in source code files.)  I don't think people should take random code for Cxx and assume blindly that it will work for Cyy.
Yes, these will break some code.  But I don't think it will break much, and it will be nice to cut down on some of these headers.  I have some very old code that defines static_assert as a macro involving typedefs with structs that can have positive or negative sizes, for C90 and C99. I don't expect to compiler these as C23 without testing - backwards compatibility is vital, but excessive backwards compatibility restricts improvements to the language.
Still, it's a valid complaint.  No change is going to please everyone!