A few of my highlights/to be aware of:
* Add nullptr constant for nullptr_t type
* Add true and false keywords
* Add ' digit separator to literal constants, such as 0xFE'DC'BA'98
* The meaning of the auto keyword was changed to cause type inference while also retaining its old meaning of a storage class specifier if used alongside a type. Unlike C++, C23 allows type inference only for object definitions (no inferring function return type or function parameter type).
* Add char8_t type for storing UTF-8 encoded data and change the type of u8 character constants and string literals to char8_t
Some of these things are stuff that I had already used in existing programs (far before C23 was invented), and a few others (e.g. #embed) are good ideas that I had also previously thought of wanting too. And, I didn't know that ={} for zero initialize was not previously considered valid (and, looking at the specification, it seems that I am not the only one), but nevertheless I had often used that too.
Another nonstandard function I often use if fopencookie, and another feature I often use is the Elvis operator, but on Wikipedia I do not see those things listed in the list of C23. And then, there is -fwrapv, which I also often use. Another thing I would want is dynamic argument lists (including but not limited to variable argument lists) constructed at run time, and the ability to control memory layout in some ways.
However, I would think that underscores would be better than using apostrophes for digit separation, to avoid messing up programs that expect the apostrophe to have its existing meaning (although I have been told that it conflicts with C++). I would think "0o" prefix for octal numbers would also be good, but it is too late to change it now. I also think that adding the Unicode string types might not be a good idea, since it might encourage APIs to use it in circumstances where it ought not to care about the character set (although it might be possible to cast the type, that just adds extra stuff). Programming languages and file formats should not assume that Unicode is the only character set, because it isn't. The source format should be ASCII (although non-ASCII bytes are allowed as well, it might be a potential security issue to allow them in some environments). I am not so sure that __has_include is really a good idea either; you can use #ifdef to check if something is defined, either already defined or by a command-line switch; it is better to allow specifying compile options to use or not use them that way instead, I think.
And, I also think that it isn't so good that the standards are not freely available, but that was always how it worked. They could change that (unlike some of the other problems with the C programming language) but they don't. At least, the drafts are available.
I don't agree. K&R 2nd edition only goes up to C89, while C99 added tons of language changes which make C a much friendlier (and dare I say: safer) language (the two biggies are designated-init and compound-literals, but also tons of smaller things, like declaring variables anywhere, "for (int...", a proper bool type, fixed width integer types (uint8_t, ...) etc etc...) - I would even go as far to say that C99 is the most important C version and almost feels like a new language compared to C89 (after C99 the changes were mostly incremental though).
The 90s were the decade when C saw its biggest improvements, and K&R 2nd edition stops just short of that.
(the book is still a good read as an interesting historical artifact - it contains a lot of wisdom that goes beyond language details - but as a language reference or learning resource it is hopelessly outdated)
C17 is the best version to target. It is a bugfix version of C11, so the feature set is older and more widely available than the date suggests. C11 includes atomics which are necessary for multicore programming.
Is there a good place to "acquire" ISO specs? I've never been able to find them in the usual collections of availability-challenged media. I often resort to google-dorking, which does usually work but it's pretty annoying.
For some, including C and C++, the standards committee works in the open and make draft standards freely available. The final draft is [edit: almost] exactly what was voted on to become the standard.
>> Specifically for the PDF Draft n3220, the only C2Y specific change that has approval is an editorial one to fix a footnote in Annex K to state "potentially reserved" rather than just "reserved". There are no other changes between the n3220 and n3219. <<
>> This draft includes some additional Introduction material and sweeping editorial changes to comply with the ISO/IEC Directives, Part 2. Most of these were to ensure that the wording was ready for publication of C23, and were merged into the current C2Y draft. This will allow people writing papers to have a proper base to work their papers from, as well as set the record straight since the last published draft of C2Y. <<
>> This report is after the publication submission process for C23 and the June 2024 Virtual Meeting which commenced adding new features and bugfixes to the next version of C, coloquially named C2Y/C2y. <<
So n3299 is identical to C23 apart from a footnote in Annex K and the version rubric. The first draft with substantive C2y changes is n3301.
