Hacker News Reader

Comment by jcranmer | Hacker News Reader

Linux is not written in C89. It is written in gnu C89, which is a mixture of C89, C99, and a panoply of often poorly-defined gcc-specific features. The number of compilers that can successfully compile Linux is one; not even clang is able to fully do so yet, I believe.

Actually, as a compiler writer, I'd go a little bit further and point out that Linux itself isn't even written to the gnu C89 very well; it's often written to a "C is portable assembly" view of the language, which results in nasty grams and invective being hurled at compiler writers if they compile the C specification correctly and not according to the "proper" assembly the code author thought they were getting.

One of the benefits of more modern language revisions is that they actually tighten the wording on a lot of the more ambiguous parts of the specification--C11 in particular adds a much more comprehensive memory model that's very shrug in the older revisions of C.

View on HN

Clang can do it. Google ships clang-built Linux kernels in Android and ChromeOS.

Can clang compile vanilla kernel without Google's forks?

Apparently OpenMandriva also uses a clang-built kernel, presumably not a Google fork. I have no personal knowledge about OpenMandriva though.

Do you consider the ClangBuiltLinux project [0] a Google fork?

[0] https://clangbuiltlinux.github.io/

AFAIK it can. They actually spent quite a considerable amount of effort implementing all of the gcc extensions to do so. There is even documentation for that: https://www.kernel.org/doc/html/latest/kbuild/llvm.html

Clang 9.0+ & Linux 5.3+ work for x86_64; I believe it's been possible to compile arm64 for longer.

Also the Kernel used in the new Valve Steam deck.

My understanding is that Linux has often faced issues where ”compiling the specification correctly” means “Ha-ha gotcha, we can actually throw half your code out of the window because you misread the deep aliasing rules on page 8432 of the spec”

Their hesitancy with newer standards is understandable, when viewed against that backdrop

One of these days, I will get around to writing my post as to why that take on undefined behavior is completely wrong.

More to the point, though, the only changes to undefined behavior in the C specification in newer versions (compared to C89) are either clarifying things that were already undefined behavior (e.g., INT_MIN % -1) or actually making some undefined behavior well-defined (e.g., allowing type punning via unions).

C23 will make calling realloc with a size of 0 into undefined behavior. [1]

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf

That falls under things that were already undefined or impossible to use properly before.

Older standards said "it is implementation-defined whether the old object is deallocated". This didn't really work well:

- if realloc(..., 0) returns NULL if it freed the object, then you have confusion with error cases. strtol already has this kind of interface and it's unusable

- if realloc(NULL, 0) returns NULL and does nothing it does something different than malloc(0). Some chose to make it do something different, some chose consistency with malloc.

- if you choose consistency with malloc then realloc(NULL, 0) likely will end end up inconsistent with realloc(ptr, 0) where ptr is not NULL. On BSDs the two are consistent but also different from any other platform, so portable code could not rely on realloc(..., 0) doing something known: either you had possible double-free bugs on some platforms, or you had a memory leak.

I'm very unhappy that they chose to make it UB rather than mandating a behavior, but in portable C89 calling `realloc(ptr, 0)` is always a bug in your code, and it was an insane thing to declare implementation-defined originally.

Reply on news.ycombinator.com