Re: "A diagram of C23 basic types"

On 02/04/2025 16:05, Muttley@DastardlyHQ.org wrote:

On Wed, 2 Apr 2025 15:35:31 +0200
David Brown <david.brown@hesbynett.no> wibbled:

On 02/04/2025 12:14, Muttley@DastardlyHQ.org wrote:

On Wed, 2 Apr 2025 10:57:29 +0100
bart <bc@freeuk.com> wibbled:

On 02/04/2025 06:59, Alexis wrote:

>
Thought people here might be interested in this image on Jens Gustedt's
blog, which translates section 6.2.5, "Types", of the C23 standard
into a graph of inclusions:
>
     https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/
>

>
So much for C being a 'simple' language.

>
C should be left alone. It does what it needs to do for a systems language.
Almost no use uses it for applications any more and sophisticated processing
using complex types for example are far better done in C++.
>
IMO, YMMV.
>

>
The C standards committee knows what C is used for.  You can be quite
confident that they have heard plenty of people say that "C should be
left alone", as well as other people say "We would like feature X to be
standardised in C".

 I suspect the people who are happy with C never have any correspondence with
anyone from the committee so they get an entirely biased sample. Just like
its usually only people who had a bad experience that fill in "How did we do"
surveys.

And I suspect that you haven't a clue who the C standards committee talk to - and who those people in turn have asked.
Of course there are plenty of people who just use whatever the compiler and library provide, without complaint or feedback of any kind, without thinking about standards, much less reading about them.  And everyone involved - the library developers, the compiler developers, the standards committee - /knows/ this.  Everyone involved /knows/ that compilers and libraries, the C implementations, will continue to support the existing standards and won't break old, working code because of new keywords or features.

 

Changes and new features are not added to the C standards just for fun,
or just to annoy people - they are there because some people want them
and expect that they can write better / faster / clearer / safer /
easier code as a result.

 And add complexity to compilers.
>

Yes.  But that's okay - it has always been acceptable to make compiler writers do more work if it is better for compiler users.

So what exactly is better / faster / clearer / safer in C23?
 

Have a little look at Annex M of the standard and you can see the list of changes:
<https://open-std.org/JTC1/SC22/WG14/www/docs/n3467.pdf>
The things I expect to use from C23 in my own work include:
1. I will gradually move over to standard attributes instead of gcc attributes where practical.  That will make code more portable.  (The attributes themselves improve static error checking and code efficiency, but that will be much the same in "-std=c23" compared to "-std=gnu17".)
2. Single-argument "static_assert", without needing macros - static assertions make code safer and sometimes more efficient, and the single-argument version makes it neater and clearer.
3. /Finally/ the old-style function declarations are dead.  "int foo();" now means what many programmers think it means, for greater safety and convenience.  Identifiers can be omitted in function definitions if they are not used, which is clearer and neater than alternatives.
4. I expect to use a few of the new library functions, such as memccpy, as safer and/or more efficient than alternatives.
5. "constexpr" for safety, efficiency and convenience.
6. "static" compound literals.
7. "typeof" and "auto" for type inference is standardised, so I don't need to use the gcc extensions for them.  These can make code safer and clearer (though their benefits are much smaller in C than C++).
8. I probably won't use _BitInt(N) types directly - their primary use will be for hardware implementation of C code in FPGAs.
9. Slightly better and safer enumeration types.
10. Bit-manipulation functions for greater portability and possibly greater efficiency.
11. nullptr for clarity and safety.
12. Some improvements to variadic macros.
13. Changes to the way "intmax_t" is defined might mean access to int128_t and uint128_t on more platforms.
14. #elifdef and #elifndef can make complicated conditional compilation a little neater.
15. #warning is now standard.
16. Binary literals are now standard.
17. Digit separators make large numbers clearer.
18. "unreachable()" is now standard.
19. printf (and friends) support for things like "%w32i" as the format specifier for int32_t, so that we no longer need the ugly PRIi32 style of macro for portable code with fixed-size types.
 From the next version beyond C23, so far there is :
1. Declarations in "if" and "switch" statements, like those in "for" loops, helps keep local variable scopes small and neat.
2. Ranges in case labels - that speaks for itself (though again I used it already as a gcc extension).
3. Hopefully the 0o and 0O octal prefixes will mean that the 0 octal prefix will be deprecated and warned about by compilers (other than for plain 0, obviously).
None of this are a big deal, and many are already things I use in my code (since I can use gcc extensions), but there are enough small benefits that I will move over to C23 on new projects.