back
24 comments
The ISO C23 standard got published as ISO/IEC 9899:2024. Public drafts can be found here: https://www.open-std.org/jtc1/sc22/wg14/www/projects#9899
Nice, thanks.

Summary of changes appears on https://en.wikipedia.org/wiki/C23_(C_standard_revision)

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.

How long before a textbook with C23 update is published?

I am asking because I am in the market for purchasing a book on the C programming language.

I am an experienced software engineer, but with experience in Java, Python, JS and other few languages. I would like to learn C and C++ deeply.

For C++, I ended up buying Stroustrup's "A tour of C++".

I am looking for something similar in C.

"The C Programming Language" 2nd edition is the bible that every C programmer read. It is a very good book.

C didn't change that much, you can just read the new standard afterwards.

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.
It is more like the old testament, relevant, but not the whole picture almost 40 years later.
I really hope llvm releases a full c23 compiler without reliance of Visual Studio with both c/c++ standard libraries.
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.

Is there a library that will loan me a copy?

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.
There are various modifications being done after the final public draft. But N3220 is very close: https://www.open-std.org/jtc1/sc22/wg14/www/projects#9899
The editor’s reports say n3299 is closer https://news.ycombinator.com/item?id=42020676
Yes, right. Thank you. (although in terms of semantic changes, I am not sure)
Library Genesis
I've searched for ISO specs there before and come up empty-handed. Maybe I was querying it wrong?
Great that the public can only read the drafts of this open standard without paying $$$.
The final draft is [edit: almost] exactly what was voted on to become the standard.
Great that I have to trust a random dude on the internet for this instead of beeing able to verify for myself /S
You can understand the status of the various drafts by looking at the editor’s reports. The ones from the last couple of meetings are:

• n3221 covering n3219 (ISO DIS Preliminary Draft) and n3220 (C2Y Working Draft

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3221.htm

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

• n3300 covering the n3299 C2y draft

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3299.pdf

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3300.htm

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

• n3302 covering the n3301 C2y draft

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3301.pdf

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3302.htm

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