3 ms·

C99 is well supported now, but Its has become increasingly clear that some of the changes to the definition of undefined behavior in the spec has made som very

C99 is well supported now, but Its has become increasingly clear that some of the changes to the definition of undefined behavior in the spec has made som very troubling compiler optimizations possible that can make C a lot less dependable. Later versions of C also adopt a new memory model that is very broken. memcopy is for instance impossible to implement in C17. Due to these issues the Linux kernel is no longer using standrard C. So as it stands C89 remains a good choice.

cesarb 7y ago
> Due to these issues the Linux kernel is no longer using standrard C. The Linux kernel never used standard C, since the very first release (0.01) it already depended on GCC extensions.
- quelsolaar 7y ago
  It has always used extensions to do things like lin line assembler, something you need when writing an operating system. What has changed is that compiler writers now interpret the new spec language in some ways that Linus thinks are broken, due to the new definition of UB. Like this: void set_value_to_zero(int * p) { if(p == NULL) throw_an_error_and_exit(); *p = 0; } In c89 writing to NULL is gives you undefined behavior. In c99 the compiler can assume that no code path will produce code that writes to NULL. That's a huge difference! It means that looking at the above code the compiler can reason: since there is a path to writing to the pointer p, the compiler can assume that p will never be NULL. Therfore p == NULL is known to be FALSE at compile time and the null test can be optimized out. I (and Linus) think this is insane.
exikyut 7y ago
Where can I read more about this?
kccqzy 7y ago
> Later versions of C also adopt a new memory model that is very broken. You mean, adopting a memory model that properly supports multi-threaded code? > memcopy is for instance impossible to implement in C17. What? I assume you mean memcpy? How is it impossible to implement given that it's implemented in the standard library? > Due to these issues the Linux kernel is no longer using standrard C. As others have mentioned, the Linux kernel never used standard C. Just search for, say, the substring "__builtin" where it uses compiler builtins directly. It's also quite recent that Linux can be compiled by clang; if it were using standard C, such compatibility issue would not arise in the first place.
- quelsolaar 7y ago
  The new memory model tried to make it possible to implement fat pointers with reference counters. That means that the compiler must be able to tell when a pointer is being copied. After the spec was ratified several people pointed out that its not possible to implement memcpy(typo sorry) since memcpy doesn't know what it is copying and might therefore copy a pointer without increasing the ref counter.

cesarb 7y ago

> Due to these issues the Linux kernel is no longer using standrard C. The Linux kernel never used standard C, since the very first release (0.01) it already depended on GCC extensions.

quelsolaar 7y ago
It has always used extensions to do things like lin line assembler, something you need when writing an operating system. What has changed is that compiler writers now interpret the new spec language in some ways that Linus thinks are broken, due to the new definition of UB. Like this: void set_value_to_zero(int * p) { if(p == NULL) throw_an_error_and_exit(); *p = 0; } In c89 writing to NULL is gives you undefined behavior. In c99 the compiler can assume that no code path will produce code that writes to NULL. That's a huge difference! It means that looking at the above code the compiler can reason: since there is a path to writing to the pointer p, the compiler can assume that p will never be NULL. Therfore p == NULL is known to be FALSE at compile time and the null test can be optimized out. I (and Linus) think this is insane.

exikyut 7y ago

Where can I read more about this?

kccqzy 7y ago

> Later versions of C also adopt a new memory model that is very broken. You mean, adopting a memory model that properly supports multi-threaded code? > memcopy is for instance impossible to implement in C17. What? I assume you mean memcpy? How is it impossible to implement given that it's implemented in the standard library? > Due to these issues the Linux kernel is no longer using standrard C. As others have mentioned, the Linux kernel never used standard C. Just search for, say, the substring "__builtin" where it uses compiler builtins directly. It's also quite recent that Linux can be compiled by clang; if it were using standard C, such compatibility issue would not arise in the first place.

quelsolaar 7y ago
The new memory model tried to make it possible to implement fat pointers with reference counters. That means that the compiler must be able to tell when a pointer is being copied. After the spec was ratified several people pointed out that its not possible to implement memcpy(typo sorry) since memcpy doesn't know what it is copying and might therefore copy a pointer without increasing the ref counter.