The C23 edition of Modern C is now available for free

> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly.

Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch ;D

(Comments about everyone's favorite niche/dead BE architecture in 3… 2… 1…)

Most important aspect of C is its portability. From small microcontrollers to almost any computing platform. I doubt that any new version of C will see that much adoption.

If I want to live on cutting edge I would rather use C++2x or Rust rather than C.

Am I missing something? What benefit this supposedly modern C offers?

Personally this[1] just makes C much more complicated for me, and I choose C when I want simplicity. If I want complicated, I would just pick C++ which I typically would never want. I would just pick Go (or Elixir if I want a server).

"_BitInt(N)" is also ugly, reminds me of "_Bool" which is thankfully "bool" now.

[1] guard, defer, auto, constexpr, nullptr (what is wrong with NULL?), etc. On top of that "constexpr" and "nullptr" just reeks of C++.

That said, Modern C is an incredible book, I have been using it for C99 (which I intend to continue sticking to).

I was going to ask if there is a good list of C books and then answered my own question. It categorizes _Modern C_ as Intermediate level.

https://stackoverflow.com/questions/562303/the-definitive-c-...

I kind of like some of Metaware's high C extensions.

https://news.ycombinator.com/item?id=41647843

https://news.ycombinator.com/item?id=38938402

I've been using modern C++ for a personal project (a language interpreter) for the last year+. I constantly think of switching to C, because of the mental burdens of C++, and because of the problems with tooling (Visual Studio's IntelliSense still barely works, because I use C++20 modules), and compile times get ugly because of the way the language failures force so much into interfaces (even with modules). But on the flip side I've gotten so used to classes, member functions, generic programming (templates), namespaces... I may be hooked.

Table of contents in the sidebar doesn't work properly for me when I click on an entry (in macOS Preview).

So happy that we still get the dinosaur mascots! This is a good book.

It's only been a few years since I've come to feel I can rely on C compilers all supporting C99, for a library I'm maintaing [1]. And after a couple of years, sure enough - I get an issue opened asking for C89 compatibility because of some arcane embedded toolchain or what-not.

So, C23? ... that's nice and all, but, let's talk about it in 20 years or so T_T

[1]: https://github.com/eyalroz/printf

Can someone link me to an article that explains why C is basically frozen at C99 for all practical purposes? Few projects worth talking about leverage features from C11 and newer

My kingdom for fully specified, well defined portable bitfields.

I wish auto in C was similar to auto in C++.

Wow, the use of attributes like [[__unsequenced__]], [[maybe_unused]] and [[noreturn]] throughout the book is really awful. It seems pretty pedantic of the author to litter all the code examples with something that is mostly optional. For a second I wondered if C23 required them.

Really looking forward to #embed, once the compilers catch up. Until then, Golang.

One of my favorite books ever.

How does "Modern" C compare safety-wise to Rust or Zig?

Wait, C programmers now put the star on the left hand side?

char* thing; // good

char *thing; // bad

This ... is awesome. As a C++ "native" I've always found the "star on the right" thing to be really horribly confusing.

any chance of getting a responsive TOC in any pdf reader whatsoever?

in example 1.1 i read that as 'tits_square' until i saw the output

Important reminder just in the Preface :-)

Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

I payed for this on manning and they didn’t even release the final version yet. I guess I didn’t understand what I was buying, but I can’t help feel a bit cheated.

Continuing to use a memory-unsafe language that has no recourse for safety and is full of footguns and is frankly irresponsible for the software profession. God help us all.

By the way, the US government did the profession no favors by including C++ as a memory-unsafe language. It is possible to write memory-safe C++, safe array dereferencing C++. But it’s not obvious how to do it. Herb Sutter is working on it with CppFront. The point stands that C++ can be memory-safe code. If you make a mistake, you might write some unsafe code in C++. But you can fix that mistake and learn to avoid it.

When you write C, you are in the bad luck shitter. You have no choice. You will write memory—unsafe code and hope you don’t fuck it up. You will hope that a refactor of your code doesn’t fuck it up.

Ah, C, so simple! You, only you, are responsible for handling memory safely. Don’t fuck it up, cadet. (Don’t leave it all to computers like a C++ developer would.)

Put C in the bin, where it belongs.

GCC support has been around since gcc 11 apparently. See table at (1). This is available in ubuntu 22.04. The page below also shows support for C26!

1) https://gcc.gnu.org/projects/cxx-status.html#:~:text=C%2B%2B...

I am worried where "official" C is going. Its syntax which is already too complex and already does too much, but that would require to "break" backward compatibility namely it would require "porting". But since it would be still "C" that amount of work should be close to "a bit" of "step by step" refactoring

For instance, only sized types:u8...s64, f32, f64... no implicit casts except for void* and literals, no integer promotion, no switch, no enum, only one loop keyword (loop{}!), no anonymous code block, and no toxic attribute like "packed structure" which makes us lose sight of data alignment... no _generic, typeof, restrict, syntax based tls, etc...

But we would need explicit atomics, explicit memory barriers, explicit unaligned memory access.

Instead of adding and complexifying C to make writing a naive compiler more and more complex, long and a mouse and cat catchup "to the standard" tedious task, what should be done is exactly the other way around.

In end, I don't trust C officials anymore, I tend to stick to C99, or even assembly (I am currently writing rv64 assembly I run an x86_64).

Do they still use 0-terminated strings/char* as the main string type?

Is the usage of single linked lists still prevalent as the main container type?