6 ms·

If the C standard org was serious about code safety the FIRST thing they would do is PUBLISH THE STANDARD!!!! Complaining that people don't follow the finer de

If the C standard org was serious about code safety the FIRST thing they would do is PUBLISH THE STANDARD!!!! Complaining that people don't follow the finer details of the standard while at the same time keeping the standard unavailable to the vast majority of C programmers is a travesty. When compiler writers think that its ok, to put "optimizations" in to compilers that remove vital NULL checks, because the the spec says that something may be UB that make no sense, I think to myself, What would they say If they downloaded the latest version of their favorite text editor, only to find that it would format their system disk when ever the user presses Control? When they then reached out to the maker of the text editor, the developers would answer: "Oh, on page 204 in the documentation that costs money to access it says that pressing Control, is undefined, we we are in our rights to format your system disk". Would they be ok with that and think it was fair? Thats how the C standard body is behaving! NOBODY learns C form the C standard, and that is your fault, so don't complain about people not following it. The fact that you are also fucking it up doesn't help: (https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/ https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/)

lqet 6y ago
A comment on your blog post. You are writing: > In C89, undefined behavior is interpreted as, “The C standard doesn’t have requirements for the behavior, so you must define what the behavior is in your implementation, and there are a few permissible options”. But isn't the sentence > Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results in the C89 spec already giving the compiler developers carte blanche to do whatever they want? Anything can be interpreted as "ignoring the situation with unpredictable results". In your criticism of C99 (where the word "permissible" was changed to "possible") you write: > In C99 undefined behavior is interpreted as, “The C standard doesn’t have requirements for the behavior, so you can do what ever you want”. [..]. If for instance you have a large codebase like say the Linux Kernel and there is a single instance of undefined behavior somewhere in there the compiler is free to produce a binary that does what ever it wants. It doesn’t have to document what it does, it doesn’t have tell the user, it doesn’t need to do anything. This exactly fits the C89 spec. The compiler may just ignore that you are relying on undefined behavior and produce a completely unpredictable binary.
- quelsolaar 6y ago
  If the change makes no difference at all, why do you think the change was made? Changes in specs are made because people lobby for them.
  - klodolph 6y ago
    I think the relevant phrase is "so you must define what the behavior is in your implementation". With simple compilers, you could more or less define what happens with undefined behavior. For example, on platform X, if you dereference NULL, you get a segfault. On platform Y, you get a zero value. Problem is these behaviors are hard to define once you start thinking about the edge cases. You can dereference NULL with an offset, and once you do that, you might skip over any guard pages and overwrite a function pointer with garbage and then jump to some random location in memory, and once you do that, all bets are off. I mean, really, really off. So that leaves you with three options. 1. Abandon the idea of defining behavior in these cases. 2. Insert bounds checks. 3. Refine the idea of undefined behavior into two separate concepts--"bounded" and "critical" undefined behavior. C has taken all three options at the same time, in a sense. The main standard takes option #1, the Address Sanitizer gives you #2 (more or less), and annex L gives you #3. Annex L, option #3 above, is in many senses the sane option--but it requires a fairly large amount of work on the part of the compiler writers, and to my knowledge neither GCC nor Clang have implemented it. I would also like to add that some of the places where we see undefined behavior were inserted into the standard for real-world cases for unusual platforms. For example, the weird rules for pointer comparisons make sense when you think about segmented memory. Relational comparisons (<, >, <=, >=, but NOT == or !=) on pointers are generally used for traversing arrays, and if you have two pointers into the same array, it would be reasonable to assume that they have the same segment (depending on your memory model)... SO, you omit the segment comparison in this case.
    - quelsolaar 6y ago
      I think there are valid reasons for a language spec to have Undefined behavior. But many UB in C would be much better if the where defined as platform specific. Like integer overflow, its very well defined on x86, ARM and every other CPU architecture in use, but not only does compilers act as if its unknowable, even when they clearly know it because they are implementing a known instruction set, they even make it hard to detect overflows since they optimize away tests since they cant happen.
aw1621107 6y ago
> The fact that you are also fucking it up doesn't help: (https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/ https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/) For the benefit of readers here who may not know, this blog post has been discussed previously on HN [0]. Personally, I don't find the argument made in the blog post convincing [0], but I'm hardly an authority on this kind of thing. I've copied part of my comment on the other thread here for reference. In any case, I think there's an argument to be made that it's not the standards committee that is at fault. ---- I'm not really convinced the author is correct in claiming that a one-word change opened the floodgates to optimizations on undefined behavior. In particular I think: > Careful reading will reveal that the word “Permissible” has been exchanged to “Possible”. In my opinion this change has lead C to go in a very problematic direction. is a red herring. In my opinion, the actual problematic phrase is this: > ignoring the situation completely with unpredictable results which didn't change between C89 and C99. It all comes down to what "ignoring the situation" should mean. Compiler vendors appear to interpret this to mean "ignore situations that invoke undefined behavior". Programmers who dislike optimizations based on undefined behavior appear to interpret this to mean "ignore the violation that leads to undefined behavior and treat it like conforming code". Who's right? It's ambiguous. ---- (Edited after noticing that you're the author of the blog post. Sorry!) [0]: https://news.ycombinator.com/item?id=22589657 https://news.ycombinator.com/item?id=22589657 [1]: https://news.ycombinator.com/item?id=22590286 https://news.ycombinator.com/item?id=22590286
- quelsolaar 6y ago
  I agree that "ignoring the situation completely with unpredictable results" is also bad, although I might be able to see some situations where it would be difficult to write a spec in a clear way that was more precise. However the problem isn't just that compilers ignore UB, they actively make use of it! In the example: if(p == NULL) write_out_error_message_and_exit(0); *p = 0; The NULL check is removed by the compiler because of the undefined behavior of writing to NULL. Instead of ignoring that the code might write to NULL, the compiler does the opposite, and assumed that p cant be NULL.
  - saagarjha 6y ago
steveklabnik 6y ago
Isn't this situation due to ISO rules, and don't they publish a "draft" that is identical to the actual standard before hitting publish, to get around those rules? Or maybe you're talking about something I don't understand.
- quelsolaar 6y ago
  Yes, but this arcane way of working isn't OK, when the entire opensource world depends on the language to produce functioning code.
  - steveklabnik 6y ago
    While I also prefer other processes, for many people, ISO standardization is really important, and so to me it seems like they're doing the best they can, given that constraint.
- thayne 6y ago
  Maybe those ISO rules should change....
Y_Y 6y ago
You can get the standard here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf (more or less)
- wtetzner 6y ago
  > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf That link seems to be broken.
  - Y_Y 6y ago
    I tested it before posting and also just now, and both times it downloaded the pdf correctly. Also see your sibling comment for other version numbers that may be more useful.
    - wtetzner 6y ago
      It's working for me now. Maybe it was just down for a short period. I wasn't getting a response from the server at the time.
- fanf2 6y ago
  That is an intermediate draft between C18 and C2x with diff markers, so it isn't the best reference to use. My notes have: http://www.open-std.org/jtc1/sc22/wg14/www/docs/ http://www.open-std.org/jtc1/sc22/wg14/www/docs/ n1256.pdf - C99 including technical corrigenda up to TC3 n1570.pdf - C11 final draft n2176.pdf - C18 final draft (password protected; C18 is basically C11 with corrections) n2478.pdf - latest C2x draft (now typeset by LaTeX instead of troff)
dang 6y ago
Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
moonchild 6y ago
The draft versions of the spec (functionally equivalent to the published versions) are freely available. I believe that the opensource compilers explicitly target those draft versions; but even if not, there's nothing in the release version that's not in the draft. You can even get fancy html formatted versions that somebody made - https://port70.net/~nsz/c/ https://port70.net/~nsz/c/

lqet 6y ago

A comment on your blog post. You are writing: > In C89, undefined behavior is interpreted as, “The C standard doesn’t have requirements for the behavior, so you must define what the behavior is in your implementation, and there are a few permissible options”. But isn't the sentence > Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results in the C89 spec already giving the compiler developers carte blanche to do whatever they want? Anything can be interpreted as "ignoring the situation with unpredictable results". In your criticism of C99 (where the word "permissible" was changed to "possible") you write: > In C99 undefined behavior is interpreted as, “The C standard doesn’t have requirements for the behavior, so you can do what ever you want”. [..]. If for instance you have a large codebase like say the Linux Kernel and there is a single instance of undefined behavior somewhere in there the compiler is free to produce a binary that does what ever it wants. It doesn’t have to document what it does, it doesn’t have tell the user, it doesn’t need to do anything. This exactly fits the C89 spec. The compiler may just ignore that you are relying on undefined behavior and produce a completely unpredictable binary.

quelsolaar 6y ago
If the change makes no difference at all, why do you think the change was made? Changes in specs are made because people lobby for them.
- klodolph 6y ago
  I think the relevant phrase is "so you must define what the behavior is in your implementation". With simple compilers, you could more or less define what happens with undefined behavior. For example, on platform X, if you dereference NULL, you get a segfault. On platform Y, you get a zero value. Problem is these behaviors are hard to define once you start thinking about the edge cases. You can dereference NULL with an offset, and once you do that, you might skip over any guard pages and overwrite a function pointer with garbage and then jump to some random location in memory, and once you do that, all bets are off. I mean, really, really off. So that leaves you with three options. 1. Abandon the idea of defining behavior in these cases. 2. Insert bounds checks. 3. Refine the idea of undefined behavior into two separate concepts--"bounded" and "critical" undefined behavior. C has taken all three options at the same time, in a sense. The main standard takes option #1, the Address Sanitizer gives you #2 (more or less), and annex L gives you #3. Annex L, option #3 above, is in many senses the sane option--but it requires a fairly large amount of work on the part of the compiler writers, and to my knowledge neither GCC nor Clang have implemented it. I would also like to add that some of the places where we see undefined behavior were inserted into the standard for real-world cases for unusual platforms. For example, the weird rules for pointer comparisons make sense when you think about segmented memory. Relational comparisons (<, >, <=, >=, but NOT == or !=) on pointers are generally used for traversing arrays, and if you have two pointers into the same array, it would be reasonable to assume that they have the same segment (depending on your memory model)... SO, you omit the segment comparison in this case.
  - quelsolaar 6y ago
    I think there are valid reasons for a language spec to have Undefined behavior. But many UB in C would be much better if the where defined as platform specific. Like integer overflow, its very well defined on x86, ARM and every other CPU architecture in use, but not only does compilers act as if its unknowable, even when they clearly know it because they are implementing a known instruction set, they even make it hard to detect overflows since they optimize away tests since they cant happen.

aw1621107 6y ago

> The fact that you are also fucking it up doesn't help: (https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/ https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/) For the benefit of readers here who may not know, this blog post has been discussed previously on HN [0]. Personally, I don't find the argument made in the blog post convincing [0], but I'm hardly an authority on this kind of thing. I've copied part of my comment on the other thread here for reference. In any case, I think there's an argument to be made that it's not the standards committee that is at fault. ---- I'm not really convinced the author is correct in claiming that a one-word change opened the floodgates to optimizations on undefined behavior. In particular I think: > Careful reading will reveal that the word “Permissible” has been exchanged to “Possible”. In my opinion this change has lead C to go in a very problematic direction. is a red herring. In my opinion, the actual problematic phrase is this: > ignoring the situation completely with unpredictable results which didn't change between C89 and C99. It all comes down to what "ignoring the situation" should mean. Compiler vendors appear to interpret this to mean "ignore situations that invoke undefined behavior". Programmers who dislike optimizations based on undefined behavior appear to interpret this to mean "ignore the violation that leads to undefined behavior and treat it like conforming code". Who's right? It's ambiguous. ---- (Edited after noticing that you're the author of the blog post. Sorry!) [0]: https://news.ycombinator.com/item?id=22589657 https://news.ycombinator.com/item?id=22589657 [1]: https://news.ycombinator.com/item?id=22590286 https://news.ycombinator.com/item?id=22590286

quelsolaar 6y ago
I agree that "ignoring the situation completely with unpredictable results" is also bad, although I might be able to see some situations where it would be difficult to write a spec in a clear way that was more precise. However the problem isn't just that compilers ignore UB, they actively make use of it! In the example: if(p == NULL) write_out_error_message_and_exit(0); *p = 0; The NULL check is removed by the compiler because of the undefined behavior of writing to NULL. Instead of ignoring that the code might write to NULL, the compiler does the opposite, and assumed that p cant be NULL.
- saagarjha 6y ago

steveklabnik 6y ago

Isn't this situation due to ISO rules, and don't they publish a "draft" that is identical to the actual standard before hitting publish, to get around those rules? Or maybe you're talking about something I don't understand.

quelsolaar 6y ago
Yes, but this arcane way of working isn't OK, when the entire opensource world depends on the language to produce functioning code.
- steveklabnik 6y ago
  While I also prefer other processes, for many people, ISO standardization is really important, and so to me it seems like they're doing the best they can, given that constraint.
thayne 6y ago
Maybe those ISO rules should change....

Y_Y 6y ago

You can get the standard here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf (more or less)

wtetzner 6y ago
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf That link seems to be broken.
- Y_Y 6y ago
  I tested it before posting and also just now, and both times it downloaded the pdf correctly. Also see your sibling comment for other version numbers that may be more useful.
  - wtetzner 6y ago
    It's working for me now. Maybe it was just down for a short period. I wasn't getting a response from the server at the time.
fanf2 6y ago
That is an intermediate draft between C18 and C2x with diff markers, so it isn't the best reference to use. My notes have: http://www.open-std.org/jtc1/sc22/wg14/www/docs/ http://www.open-std.org/jtc1/sc22/wg14/www/docs/ n1256.pdf - C99 including technical corrigenda up to TC3 n1570.pdf - C11 final draft n2176.pdf - C18 final draft (password protected; C18 is basically C11 with corrections) n2478.pdf - latest C2x draft (now typeset by LaTeX instead of troff)

dang 6y ago

Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.

moonchild 6y ago

The draft versions of the spec (functionally equivalent to the published versions) are freely available. I believe that the opensource compilers explicitly target those draft versions; but even if not, there's nothing in the release version that's not in the draft. You can even get fancy html formatted versions that somebody made - https://port70.net/~nsz/c/ https://port70.net/~nsz/c/