5 ms·

To me, this rant seems more directed at C standards people than the guy he sent it to. That doesn't excuse his vitriol, but I hope people will read between the

by pubby 8y ago

To me, this rant seems more directed at C standards people than the guy he sent it to. That doesn't excuse his vitriol, but I hope people will read between the lines. Sometimes people forget that C was created for writing operating systems. They get in their mind that C is all about high-performance, and that making it competitive with FORTRAN is the way to go. I understand that, but it's not what C was created for. If the world's most famous C programmer and OS guru wants to have strong opinions on the direction of the language, I say allow it.

raverbashing 8y ago
Yes. From the article: " The standard simply is not important, when it is in direct conflict with reality and reliable code generation."
zwischenzug 8y ago
His rant seems directed against the _argument_ that standards should be followed without question.
simias 8y ago
>C was created for writing operating systems That doesn't properly justify C's minefield around aliasing and type punning in general. It's UB galore. Thing is, whenever you're writing low level code that's tied to hardware in my experience you very often end up having to pun your types to match hardware constraints, and at this point the C standard basically says "lol good luck with that bro". I'm not a programming language expert but IMO at the very least C should make reading from a different union member than was last written to "implementation defined" instead of UB (with suitable constraints if the sizes of the members differ I suppose). In effect that's mostly how compilers deal with that anyway. So I agree with Linus that the C standard is really unhelpful in these situation, although his childish anger is unnecessary and counter-productive.
- pubby 8y ago
  >at the very least C should make reading from a different union member than was last written to "implementation defined" That's how it is :) The standard even describes union behavior as "type punning". I don't know if C++ allows it though.
  - maccard 8y ago
    Don’t think c++ allows it. Last time I checked, if you use any modern compiler, and do a memcpy, and check the assembly, it does the right thing.
    - saagarjha 8y ago
      Yes, that's the "approved" way of doing type punning. Any decent compiler will immediately optimize that down to nothing.
  - simias 8y ago
    You're right, apparently it changed in C99 so my knowledge is pretty out of date. Thank you for pointing it out.
  - TorKlingberg 8y ago
    Type punning through a union is allowed, buy you have to be careful so the compiler can see the union. union { int i; float f; } u; You can't safely call a function with pointers to the members like func(&u.i, &u.f), because when func was compiled, the compiler couldn't know that the arguments are pointers to union members. This sort of thing scares me, because what the compiler can "see" isn't well defined. Is it ok if func is in the same file? Probably not. How about if I don't send the pointers to an other function and just use them locally? Probably ok, but I wouldn't trust it. If you want to type pun with a union, make sure to always access the members through the union, not with direct pointers. The only method of type punning I 100% trust is memcpy, and if you get lucky the compiler might optimize away the overhead for you.
    - boomlinde 8y ago
- B1FF_PSUVM 8y ago
  > childish anger The whole world needs betrization soonest ( https://en.wikipedia.org/wiki/Return_from_the_Stars https://en.wikipedia.org/wiki/Return_from_the_Stars )
- boomlinde 8y ago
  Maybe I suck at reading the standard, but it seems that type punning via unions is defined in C99: "If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning")."
phicoh 8y ago
The problem is in how the gcc (and to some extent clang) maintainers read the standard. If the C standard says: the following construct is undefined, then as a compiler writer you have two options: you try to figure out what is sensible in this context, or you do something crazy that conforms to a literal interpretation. For operating system code, you want the compiler to something sensible. Life is already hard enough. In just about all cases where the C standard introduces undefined behaviour, there is an obvious interpretation that makes sense to most C programmers. If you want to get the highest possible score in a benchmark, you write a compiler that drops code left and right if you can prove that the code invoked undefined behaviour. Unfortunately, compiler writers, in particular the maintainers of gcc, seem to care more about this ratrace than to write a good compiler for compiling operating system code.
- alexeiz 8y ago
  > If the C standard says: the following construct is undefined, then as a compiler writer you have two options: you try to figure out what is sensible in this context, or you do something crazy that conforms to a literal interpretation. Not exactly. Rather, the compiler is not constrained by any particular behavior of the construct which is said to be undefined. So if there is an optimization that changes the meaning of the undefined construct, it's all fair game, because the construct was not defined in the first place.
  - phicoh 8y ago
    That's exactly the problem. Somewhere a programmer working on a compiler is coding an optimization that make a program run faster, but gives a different result from what the writer of the program intended. That's only useful if you only care about the total run time of the program and not about what it is trying to achieve.
richmarr 8y ago
Except "strong opinions" is not what happened here. He's being verbally abusive. I think it'd be helpful to be able to talk about this behaviour without needing to suger-coat it as "opinions". There are far less damaging ways to say exactly the same things as Tovalds says, and someone with his position in the community should know better. Punch up if you like, not down.
- Gibbon1 8y ago
  I think he's not really ranting at the guy submitting the patch. He's ranting at the the c standard committee and the compiler maintainers with their optimization fetish[1]. While at the same time redrawing a line in the sand. [1] It's an open secret that most of the optimizations introduced in the last ten years provide no real benefit while making programs harder to reason about and trust. While at the same time the gcc backend is a trashfire. Hint, Microsoft's VC compiler produces better assembly code without any of these 'optimizations'

by pubby 8y ago

raverbashing 8y ago

Yes. From the article: " The standard simply is not important, when it is in direct conflict with reality and reliable code generation."

zwischenzug 8y ago

His rant seems directed against the _argument_ that standards should be followed without question.

simias 8y ago

>C was created for writing operating systems That doesn't properly justify C's minefield around aliasing and type punning in general. It's UB galore. Thing is, whenever you're writing low level code that's tied to hardware in my experience you very often end up having to pun your types to match hardware constraints, and at this point the C standard basically says "lol good luck with that bro". I'm not a programming language expert but IMO at the very least C should make reading from a different union member than was last written to "implementation defined" instead of UB (with suitable constraints if the sizes of the members differ I suppose). In effect that's mostly how compilers deal with that anyway. So I agree with Linus that the C standard is really unhelpful in these situation, although his childish anger is unnecessary and counter-productive.

pubby 8y ago
>at the very least C should make reading from a different union member than was last written to "implementation defined" That's how it is :) The standard even describes union behavior as "type punning". I don't know if C++ allows it though.
- maccard 8y ago
  Don’t think c++ allows it. Last time I checked, if you use any modern compiler, and do a memcpy, and check the assembly, it does the right thing.
  - saagarjha 8y ago
    Yes, that's the "approved" way of doing type punning. Any decent compiler will immediately optimize that down to nothing.
- simias 8y ago
  You're right, apparently it changed in C99 so my knowledge is pretty out of date. Thank you for pointing it out.
- TorKlingberg 8y ago
  Type punning through a union is allowed, buy you have to be careful so the compiler can see the union. union { int i; float f; } u; You can't safely call a function with pointers to the members like func(&u.i, &u.f), because when func was compiled, the compiler couldn't know that the arguments are pointers to union members. This sort of thing scares me, because what the compiler can "see" isn't well defined. Is it ok if func is in the same file? Probably not. How about if I don't send the pointers to an other function and just use them locally? Probably ok, but I wouldn't trust it. If you want to type pun with a union, make sure to always access the members through the union, not with direct pointers. The only method of type punning I 100% trust is memcpy, and if you get lucky the compiler might optimize away the overhead for you.
  - boomlinde 8y ago
B1FF_PSUVM 8y ago
> childish anger The whole world needs betrization soonest ( https://en.wikipedia.org/wiki/Return_from_the_Stars https://en.wikipedia.org/wiki/Return_from_the_Stars )
boomlinde 8y ago
Maybe I suck at reading the standard, but it seems that type punning via unions is defined in C99: "If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning")."

phicoh 8y ago

The problem is in how the gcc (and to some extent clang) maintainers read the standard. If the C standard says: the following construct is undefined, then as a compiler writer you have two options: you try to figure out what is sensible in this context, or you do something crazy that conforms to a literal interpretation. For operating system code, you want the compiler to something sensible. Life is already hard enough. In just about all cases where the C standard introduces undefined behaviour, there is an obvious interpretation that makes sense to most C programmers. If you want to get the highest possible score in a benchmark, you write a compiler that drops code left and right if you can prove that the code invoked undefined behaviour. Unfortunately, compiler writers, in particular the maintainers of gcc, seem to care more about this ratrace than to write a good compiler for compiling operating system code.

alexeiz 8y ago
> If the C standard says: the following construct is undefined, then as a compiler writer you have two options: you try to figure out what is sensible in this context, or you do something crazy that conforms to a literal interpretation. Not exactly. Rather, the compiler is not constrained by any particular behavior of the construct which is said to be undefined. So if there is an optimization that changes the meaning of the undefined construct, it's all fair game, because the construct was not defined in the first place.
- phicoh 8y ago
  That's exactly the problem. Somewhere a programmer working on a compiler is coding an optimization that make a program run faster, but gives a different result from what the writer of the program intended. That's only useful if you only care about the total run time of the program and not about what it is trying to achieve.

richmarr 8y ago

Except "strong opinions" is not what happened here. He's being verbally abusive. I think it'd be helpful to be able to talk about this behaviour without needing to suger-coat it as "opinions". There are far less damaging ways to say exactly the same things as Tovalds says, and someone with his position in the community should know better. Punch up if you like, not down.

Gibbon1 8y ago
I think he's not really ranting at the guy submitting the patch. He's ranting at the the c standard committee and the compiler maintainers with their optimization fetish[1]. While at the same time redrawing a line in the sand. [1] It's an open secret that most of the optimizations introduced in the last ten years provide no real benefit while making programs harder to reason about and trust. While at the same time the gcc backend is a trashfire. Hint, Microsoft's VC compiler produces better assembly code without any of these 'optimizations'