5 ms·

1. The people creating the C standard were adamant that just following the standard was not sufficient to produce a "fit-for-purpose" compiler. This was intent

1. The people creating the C standard were adamant that just following the standard was not sufficient to produce a "fit-for-purpose" compiler. This was intentional. 2. They were also adamant that being a "portable assembler" with predictable, machine-level semantics was an explicit goal of the standard. 3. The C standard actually does have text giving a list of acceptable behaviours for a compiler and "silently remove the code" is not in that list. And this text used to be normative, but was later made non-normative. So I blame the people who messed with the standard, and guess who those people were?

pwdisswordfishc 3y ago
Citation needed. Which people? What did they actually say? What was the text that supposedly forbade this interpretation of UB? Please don't tell me this is again that tired wankery over "permissible" versus "possible". As if the choice of synonym mattered.
- 3836293648 3y ago
  It's a rather infamous change between C89 and C99 where the description of UB was changed from basically don't do this to please do this and compilers can do whatever they want if you do
  - _kst_ 3y ago
    The definition of "undefined behavior" did not change in the way you describe between C89/C90 and C99. In both editions, one possible consequence of undefined behavior is "ignoring the situation completely with unpredictable results" -- i.e., compilers can do whatever they want. There is no "don't do this" or "please do this" in either edition. Both merely describe the possible consequences if you do. C90: undefined behavior: Behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which the Standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). If a "shall" or "shall not" requirement that appears outside of a constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this Standard by the words "undefined behavior" or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe "behavior that is undefined." C99: undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). EXAMPLE An example of undefined behavior is the behavior on integer overflow. (Some of the wording in the C90 definition was moved to the Conformance section in C99.)
    - mpweiher 3y ago
      “Permissible” ≠ “possible”
      - _kst_ 3y ago
        True -- but how does that affect the semantics? Both definitions say that undefined behavior can be dealt with by "ignoring the situation completely with unpredictable results". There are no restrictions on what can happen. (The standard joke is that it can make demons fly out of your nose. Of course that's not physically possible, but it would not violate the standard.)
        mpweiher 3y ago
        Ignoring ≠ taking action based on The standard joke is a joke, because it is wrong.
        nlewycky 3y ago
        > The standard joke is a joke, because it is wrong. No, it is a joke because it is silly. It is correct and intended for pedagogy.
        muldvarp 3y ago
        > The standard joke is a joke, because it is wrong. No, it's a joke because it's _physically_ impossible but allowed. That said, clang and gcc are of course not antagonistic and don't make use of UB to anger their users. Instead, they make use of UB to aggressively optimize (valid) programs, which is important because C is used for a lot of high-performance code where every bit of optimization can save a lot of time and money. The fact that this sometimes leads to invald programs (i.e. programs with no defined behavior according to the standard) being optimized to correct but "absurd" results is just a trade-off compiler writers like to take. Mostly because such programs are erroneous anyway, even under a strict "portable assembler" view, which again the standard does not enforce (or even encourage).
        deleted 3y ago
        [deleted]
- mpweiher 3y ago
  "Permissible" and "possible" are not synonyms.
- memefrog 3y ago
  If they mean the same thing, why was it changed? Hint: they don't mean the same thing. At all.
  - muldvarp 3y ago
    You have never changed the wording of anything you had written to make your intent clearer?
moefh 3y ago
> The C standard actually does have text giving a list of acceptable behaviours for a compiler The exact opposite is explicitly stated in the standard (from C11 section 3.4.3): undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements The standard then lists some examples of undefined behavior, and it's true that "silently removing the code" is not in the list. Still, I think it's pretty clear that it's acceptable behavior, since the standard just stated it imposes no requirements.
- User23 3y ago
  I think you’re misinterpreting. Maybe it’s clearer if we elide the relative subclause: undefined behavior behavior … for which this International Standard imposes no requirements That is an obvious definition of what is undefined behavior. It’s not giving license to do whatever. That said the ship has sailed and what implementors do obviously matters more than what the standard says.
  - iso8859-1 3y ago
    If there are no requirements on what it's doing, how is that not a license to do whatever? There is not even a requirement that a theoretical program that contains e.g. only preceding code, would still maintain any invariants. So I don't see what an instance of "whatever" that violates "no requirements" would look like.
    - User23 3y ago
      Read with an either an atypical or malicious degree of literalism the standard supports ransomwaring your machine and indeed your entire network in the face of undefined behavior. What it actually means is the standard doesn’t require doing the impossible, not that a program error is license to generate malicious code. That’s why it gives a (now formerly) normative list of possible approaches.
      - 3y ago
_kst_ 3y ago
C is not a "portable assembler". An assembly language program specifies a series of CPU instructions. A C program specifies runtime behavior. That's a huge semantic difference.
- mpweiher 3y ago
  "Committee did not want to force programmers into writing portably, to preclude the use of C as a “high-level assembler:” https://www.open-std.org/JTC1/SC22/WG14/www/docs/n897.pdf https://www.open-std.org/JTC1/SC22/WG14/www/docs/n897.pdf p10, line 39 "C code can be portable. " line 30

pwdisswordfishc 3y ago

Citation needed. Which people? What did they actually say? What was the text that supposedly forbade this interpretation of UB? Please don't tell me this is again that tired wankery over "permissible" versus "possible". As if the choice of synonym mattered.

3836293648 3y ago
It's a rather infamous change between C89 and C99 where the description of UB was changed from basically don't do this to please do this and compilers can do whatever they want if you do
- _kst_ 3y ago
  The definition of "undefined behavior" did not change in the way you describe between C89/C90 and C99. In both editions, one possible consequence of undefined behavior is "ignoring the situation completely with unpredictable results" -- i.e., compilers can do whatever they want. There is no "don't do this" or "please do this" in either edition. Both merely describe the possible consequences if you do. C90: undefined behavior: Behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which the Standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). If a "shall" or "shall not" requirement that appears outside of a constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this Standard by the words "undefined behavior" or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe "behavior that is undefined." C99: undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). EXAMPLE An example of undefined behavior is the behavior on integer overflow. (Some of the wording in the C90 definition was moved to the Conformance section in C99.)
  - mpweiher 3y ago
    “Permissible” ≠ “possible”
    - _kst_ 3y ago
      True -- but how does that affect the semantics? Both definitions say that undefined behavior can be dealt with by "ignoring the situation completely with unpredictable results". There are no restrictions on what can happen. (The standard joke is that it can make demons fly out of your nose. Of course that's not physically possible, but it would not violate the standard.)
      - mpweiher 3y ago
        Ignoring ≠ taking action based on The standard joke is a joke, because it is wrong.
        nlewycky 3y ago
        > The standard joke is a joke, because it is wrong. No, it is a joke because it is silly. It is correct and intended for pedagogy.
        muldvarp 3y ago
        > The standard joke is a joke, because it is wrong. No, it's a joke because it's _physically_ impossible but allowed. That said, clang and gcc are of course not antagonistic and don't make use of UB to anger their users. Instead, they make use of UB to aggressively optimize (valid) programs, which is important because C is used for a lot of high-performance code where every bit of optimization can save a lot of time and money. The fact that this sometimes leads to invald programs (i.e. programs with no defined behavior according to the standard) being optimized to correct but "absurd" results is just a trade-off compiler writers like to take. Mostly because such programs are erroneous anyway, even under a strict "portable assembler" view, which again the standard does not enforce (or even encourage).
      - deleted 3y ago
        [deleted]
mpweiher 3y ago
"Permissible" and "possible" are not synonyms.
memefrog 3y ago
If they mean the same thing, why was it changed? Hint: they don't mean the same thing. At all.
- muldvarp 3y ago
  You have never changed the wording of anything you had written to make your intent clearer?

moefh 3y ago

> The C standard actually does have text giving a list of acceptable behaviours for a compiler The exact opposite is explicitly stated in the standard (from C11 section 3.4.3): undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements The standard then lists some examples of undefined behavior, and it's true that "silently removing the code" is not in the list. Still, I think it's pretty clear that it's acceptable behavior, since the standard just stated it imposes no requirements.

User23 3y ago
I think you’re misinterpreting. Maybe it’s clearer if we elide the relative subclause: undefined behavior behavior … for which this International Standard imposes no requirements That is an obvious definition of what is undefined behavior. It’s not giving license to do whatever. That said the ship has sailed and what implementors do obviously matters more than what the standard says.
- iso8859-1 3y ago
  If there are no requirements on what it's doing, how is that not a license to do whatever? There is not even a requirement that a theoretical program that contains e.g. only preceding code, would still maintain any invariants. So I don't see what an instance of "whatever" that violates "no requirements" would look like.
  - User23 3y ago
    Read with an either an atypical or malicious degree of literalism the standard supports ransomwaring your machine and indeed your entire network in the face of undefined behavior. What it actually means is the standard doesn’t require doing the impossible, not that a program error is license to generate malicious code. That’s why it gives a (now formerly) normative list of possible approaches.
    - 3y ago

_kst_ 3y ago

C is not a "portable assembler". An assembly language program specifies a series of CPU instructions. A C program specifies runtime behavior. That's a huge semantic difference.

mpweiher 3y ago
"Committee did not want to force programmers into writing portably, to preclude the use of C as a “high-level assembler:” https://www.open-std.org/JTC1/SC22/WG14/www/docs/n897.pdf https://www.open-std.org/JTC1/SC22/WG14/www/docs/n897.pdf p10, line 39 "C code can be portable. " line 30