8 ms·

C90 is partly to blame is here. It rejects sensible code due to limitations of hardware and compilers older than Linux itself. I find it hard to believe that a

by pornel 7y ago

C90 is partly to blame is here. It rejects sensible code due to limitations of hardware and compilers older than Linux itself. I find it hard to believe that a decades old compiler with an actual compile-in-one-pass limitation would produce something useful from the current kernel source. It's affecting the the entire kernel development just so that someone somewhere with an abandonware compiler doesn't get a shock of updating it once every 30 years.

temac 7y ago
Linux only compiles with at least semi-recent compilers. The minimum version for GCC even has been bumped not too long ago. They certainly are able to handle C99 style declarations. Why Linus hate them, I don't know, probably he could be able to formulate some pseudo justifications when in reality it is just what he is used to. The only thing I could find quickly was from 2005: https://lkml.org/lkml/2005/12/13/223 https://lkml.org/lkml/2005/12/13/223 Maybe it made sense in 2005, but 14 years later this might not be that much important anymore. To be honest I'm radically against the opinion that "Putting variables in the middle of code only improves readability when you have messy code", but I kind of understand where it comes from, with an hardcore old-school C mindset. With experience with more modern programming languages and considering code like more abstract level object instead of low level immediate imperative instructions, not putting declarations before the variable are needed makes sense. This is more in line with how modern compiler work AND more importantly with what we need to do to reason on code (not surprising because part of the reasoning is the same for a modern compiler and for us), and I suspect that this actually leads to less programming errors, including the silly ones we saw here.
- ncmncm 7y ago
  It is of a piece with forbidding link-compatible C++ components. Destructors prevent far more mistakes than they cause, and templates, used correctly, are much more specific and less error-prone than macros.
  - kevin_thibedeau 7y ago
    C++ is broken without exceptions. Exceptions aren't ever going to enter the kernel even if you tried to hide them behind a C ABI.
    - nickpsecurity 7y ago
      The folks behind the Pistachio microkernel said they used C++: https://github.com/l4ka/pistachio https://github.com/l4ka/pistachio I don't know if it has exceptions or an unusual style since I don't know C++. It is written by CompSci researchers which usually means a different style. Just throwing it out there for anyone considering C++ in kernels since the L4 kernels were all really fast and lean.
      - kevin_thibedeau 7y ago
        And Google merrily uses C++ with exceptions disabled. That doesn't make it right when the shit hits the fan. "Works most of the time" is not acceptable in an OS.
        nickpsecurity 7y ago
        Your statement equates not using exceptions with no error handling at all. Are exceptions the only way C++ can handle errors? Or can it do things like return codes used in C or advanced constructs via its metaprogramming?
        tomjakubowski 7y ago
        You can use error codes or, better, a Result<T, E> template in C++, but throwing an exception is the only sane way to signal an error from a C++ constructor that I know of. The alternatives are awkward: you either stick an error code on the struct, which the caller can check after construction, or write an error code to the caller through an out parameter. In either case, the class implementation now must be concerned with handling objects in some partly-initialized, "error" state.
commandlinefan 7y ago
Yeah - the original code would have been just fine, wouldn't it? It looks like the warning actually made things worse (although I can't imagine what was going through the mind of the guy who swapped the lines to silence the warning...)
aidenn0 7y ago
Yeah, the blame is about 50-50 on C89/90 vs the developer. There are at least 2 different ways to fix the warning that are brainless and semantically identical: { SNIP1 X Y = Z; SNIP2 } Either: { X Y; SNIP1 Y=Z; SNIP2 } or { SNIP1 { X Y = Z; SNIP2 } } But the need for doing this really should be removed; I agree that every compiler that can compile the linux kernel can compile the original code correctly and that most of them can do so without wholesale opting in to C99. Furthermore VLAs are the only truly crazy part of C99, so it would be nice to transition to C99 minus VLA, which is something that most compilers can enforce (gcc has -Wvla).

by pornel 7y ago

temac 7y ago

Linux only compiles with at least semi-recent compilers. The minimum version for GCC even has been bumped not too long ago. They certainly are able to handle C99 style declarations. Why Linus hate them, I don't know, probably he could be able to formulate some pseudo justifications when in reality it is just what he is used to. The only thing I could find quickly was from 2005: https://lkml.org/lkml/2005/12/13/223 https://lkml.org/lkml/2005/12/13/223 Maybe it made sense in 2005, but 14 years later this might not be that much important anymore. To be honest I'm radically against the opinion that "Putting variables in the middle of code only improves readability when you have messy code", but I kind of understand where it comes from, with an hardcore old-school C mindset. With experience with more modern programming languages and considering code like more abstract level object instead of low level immediate imperative instructions, not putting declarations before the variable are needed makes sense. This is more in line with how modern compiler work AND more importantly with what we need to do to reason on code (not surprising because part of the reasoning is the same for a modern compiler and for us), and I suspect that this actually leads to less programming errors, including the silly ones we saw here.

ncmncm 7y ago
It is of a piece with forbidding link-compatible C++ components. Destructors prevent far more mistakes than they cause, and templates, used correctly, are much more specific and less error-prone than macros.
- kevin_thibedeau 7y ago
  C++ is broken without exceptions. Exceptions aren't ever going to enter the kernel even if you tried to hide them behind a C ABI.
  - nickpsecurity 7y ago
    The folks behind the Pistachio microkernel said they used C++: https://github.com/l4ka/pistachio https://github.com/l4ka/pistachio I don't know if it has exceptions or an unusual style since I don't know C++. It is written by CompSci researchers which usually means a different style. Just throwing it out there for anyone considering C++ in kernels since the L4 kernels were all really fast and lean.
    - kevin_thibedeau 7y ago
      And Google merrily uses C++ with exceptions disabled. That doesn't make it right when the shit hits the fan. "Works most of the time" is not acceptable in an OS.
      - nickpsecurity 7y ago
        Your statement equates not using exceptions with no error handling at all. Are exceptions the only way C++ can handle errors? Or can it do things like return codes used in C or advanced constructs via its metaprogramming?
        tomjakubowski 7y ago
        You can use error codes or, better, a Result<T, E> template in C++, but throwing an exception is the only sane way to signal an error from a C++ constructor that I know of. The alternatives are awkward: you either stick an error code on the struct, which the caller can check after construction, or write an error code to the caller through an out parameter. In either case, the class implementation now must be concerned with handling objects in some partly-initialized, "error" state.

commandlinefan 7y ago

Yeah - the original code would have been just fine, wouldn't it? It looks like the warning actually made things worse (although I can't imagine what was going through the mind of the guy who swapped the lines to silence the warning...)

aidenn0 7y ago

Yeah, the blame is about 50-50 on C89/90 vs the developer. There are at least 2 different ways to fix the warning that are brainless and semantically identical: { SNIP1 X Y = Z; SNIP2 } Either: { X Y; SNIP1 Y=Z; SNIP2 } or { SNIP1 { X Y = Z; SNIP2 } } But the need for doing this really should be removed; I agree that every compiler that can compile the linux kernel can compile the original code correctly and that most of them can do so without wholesale opting in to C99. Furthermore VLAs are the only truly crazy part of C99, so it would be nice to transition to C99 minus VLA, which is something that most compilers can enforce (gcc has -Wvla).