Moving the kernel to modern C

Posted Feb 25, 2022 22:20 UTC (Fri) by NYKevin (subscriber, #129325)
In reply to: Moving the kernel to modern C by iabervon
Parent article: Moving the kernel to modern C

Unfortunately, this is probably UB: https://en.cppreference.com/w/c/language/extern

> The entire program may have zero or one external definition of every identifier with external linkage.
>
> If an identifier with external linkage is used in any expression other than a non-VLA, (since C99) sizeof, or _Alignof (since C11), there must be one and only one external definition for that identifier somewhere in the entire program.

There's no exception for short-circuit operators. If you use it at compile time, for anything other than sizeof, then it has to exist (have storage allocated somewhere).

Moving the kernel to modern C

Posted Feb 26, 2022 0:56 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

It's an UB according to the standard. But Linus very rarely is concerned with that: he tends to accept such stupidity only when there are no way convince compiler to stop breaking sane (from Linux developer's POV!) code.

It's one of the reasons about why GCC is the only supported compiler, BTW.

And GCC not just supports that feature, it even provides __attribute__((__error(msg))) extensions to make error messages more explicit. And GLibC uses it to define __errordecl macro.

Moving the kernel to modern C

Posted Feb 26, 2022 2:34 UTC (Sat) by foom (subscriber, #14868) [Link]

And this sort of bad idea is why the kernel is only possible to compile with optimizations enabled.

It would be a lot better if Linux used c++ constexpr functions and templates for compile time evaluation semantics, instead of abusing the optimizer to very poorly emulate them.