6 ms·

> Sorry, no can do. If that's the contract than C is a completely useless language. That is the contract. Your inference may be correct, but it does no good to

> Sorry, no can do. If that's the contract than C is a completely useless language. That is the contract. Your inference may be correct, but it does no good to insist that C should behave differently than it does. There are better options.

mpweiher 5y ago
Nope, that's not the contract.
- Filligree 5y ago
  I have always been told that, if a program contains UB, then the computer is justified in doing anything at all. This would naturally imply I am required to avoid any UB. Do you disagree with this?
  - marcosdumay 5y ago
    There's no contract. Nobody ever shared a piece of paper saying "your software must not use UB". The closest thing to a "contract" a language has is training material and reference books. And guess what, nearly all of C material mostly ignore UB, because enumerating it all is completely impractical even for reference books. Most of the C software in use on the wild was created before the hyper-optimization trend of C compilers, when your program did mostly what you said, and if what you said is undefined, it would still behave in some way that is close to a literal reading of the code. For most of the C software that exists, the modern treatment of UB is a huge post-facto unilateral contract change.
    - plorkyeran 5y ago
      The C specification is the contract between you and the compiler.
      - mpweiher 5y ago
        Yep. The creators of the standard spoke to this: "The three-fold definition of compliance is used to broaden the population of conforming programs and distinguish between conforming programs using a single implementation and portable conforming programs. A strictly conforming program is another term for a maximally portable program. The goal is to give the programmer a fighting chance to make powerful C programs that are also highly portable, without demeaning perfectly useful C programs that happen not to be portable. Thus the adverb strictly. By defining conforming implementations in terms of the programs they accept, the Standard leaves open the door for a broad class of extensions as part of a conforming implementation. By defining both conforming hosted and conforming freestanding implementations, the Standard recognizes the use of C to write such programs as operating systems and ROM-based applications, as well as more conventional hosted applications. Beyond this two-level scheme, no additional subsetting is defined for C, since the Committee felt strongly that too many levels dilutes the effectiveness of a standard. Conforming program is thus the most tolerant of all categories, since only one conforming implementation need accept a program to rule it conforming. The primary limitation on this license is §2.1.1.3. " It turns out it's not an all-or-nothing thing. Not being "strictly conforming" is not a "breach of the contract" by the developer, and thus license for the compiler to do anything they want. See also: "Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. " http://port70.net/~nsz/c/c89/rationale/a.html http://port70.net/~nsz/c/c89/rationale/a.html
      - marcosdumay 5y ago
        It's not a contract if you can't expect one of the parties to have read it. Compiler developers do not need a contract with the users. No compiler team works with that impression. No compiler user expects one either. But if you want to use it to justify some impractical behavior, well, both your justification is a complete fabrication, and justifying it is completely meaningless. It doesn't become practical because you have some sociological theory.
  - mpweiher 5y ago
    > I have always been told that, if a program contains UB, then the computer is justified in doing anything at all You have been told wrong. That's the point. 1. The C standard actually contains language that says what actions are permitted. These do not include "anything at all". 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). This was initially a binding part of the standard. Later versions of the standard still include this language, but made it non-binding. Which certain people interpreted as "the standard now says the exact opposite of what is literally in the text of the standard". 2. The C standard is and always was a compromise document, not a complete definition, in order to make it possible for the standard to be applicable to a wide variety of compilers on a very wide variety of different kinds of machines. It is thus by necessity and intention incomplete. Hence IDB and UB. That is, being compliant with the C standard is not sufficient to be useful implementation of C, something that is (or at least was) stated explicitly in the standard. This language might have been purged from newer versions of the standard, but it was there originally.
    - josephcsible 5y ago
      Why do you think "unpredictable results" doesn't mean "anything at all", especially when the sentence before that one, that you conveniently didn't quote, says UB is behavior "for which the Standard imposes no requirement"? And that's what it's said all the way since C89.
      - mpweiher 5y ago
        > Why do you think "unpredictable results" doesn't mean "anything at all" Why do you think it does?? If I roll dice, the exact number that will come up is unpredictable. However, the result will not be pink elephants parachuting through the roof. Once again, the standard then goes on to clarify what it means by "unpredictable": 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 that isn't clear enough, there is also the rationale: http://port70.net/~nsz/c/c89/rationale/a.html#1-5 http://port70.net/~nsz/c/c89/rationale/a.html#1-5 "The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe." Hmm...how can that be? Let's dig further: "Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. " Why doesn't this say "UB gives the implementor license to do anything at all"? Maybe because that wasn't the intention behind or purpose of UB? Let's dig further to "Compliance" "The three-fold definition of compliance is used to broaden the population of conforming programs and distinguish between conforming programs using a single implementation and portable conforming programs. " Hmm...according to the "standard purists", there is only one level of conformance: full conformance to the standard, everything else means the compiler can do anything it wants. Strangely, the standard itself disagrees. Let's look some more: "Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. " Again, the exact opposite of what the "standard extremists" claim. There are those who poo-pooh the idea that C is a "portable assembler". Here is what the rationale document says: "C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the Committee did not want to force programmers into writing portably, to preclude the use of C as a ``high-level assembler'': the ability to write machine-specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program" So the C standards committee explicitly sought C to be usable as a "high-level assembler". Who would have thunk? Apart from everybody who actually knows about the spirit of C. What is nonsense is this "spirit"? Well the rational says this: "The Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based. Some of the facets of the spirit of C can be summarized in phrases like - Trust the programmer. - Don't prevent the programmer from doing what needs to be done. - Keep the language small and simple. - Provide only one way to do an operation. - Make it fast, even if it is not guaranteed to be portable. The last proverb needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine's hardware does it rather than by a general abstract rule. " Hmm...
- 3836293648 5y ago
  That's absolutely the contract compiler implementors are following. If you don't want to be a part of that contract you need to implement your own compiler from the ground up with optimisations based on your interpretation of UB.

mpweiher 5y ago

Nope, that's not the contract.

Filligree 5y ago
I have always been told that, if a program contains UB, then the computer is justified in doing anything at all. This would naturally imply I am required to avoid any UB. Do you disagree with this?
- marcosdumay 5y ago
  There's no contract. Nobody ever shared a piece of paper saying "your software must not use UB". The closest thing to a "contract" a language has is training material and reference books. And guess what, nearly all of C material mostly ignore UB, because enumerating it all is completely impractical even for reference books. Most of the C software in use on the wild was created before the hyper-optimization trend of C compilers, when your program did mostly what you said, and if what you said is undefined, it would still behave in some way that is close to a literal reading of the code. For most of the C software that exists, the modern treatment of UB is a huge post-facto unilateral contract change.
  - plorkyeran 5y ago
    The C specification is the contract between you and the compiler.
    - mpweiher 5y ago
      Yep. The creators of the standard spoke to this: "The three-fold definition of compliance is used to broaden the population of conforming programs and distinguish between conforming programs using a single implementation and portable conforming programs. A strictly conforming program is another term for a maximally portable program. The goal is to give the programmer a fighting chance to make powerful C programs that are also highly portable, without demeaning perfectly useful C programs that happen not to be portable. Thus the adverb strictly. By defining conforming implementations in terms of the programs they accept, the Standard leaves open the door for a broad class of extensions as part of a conforming implementation. By defining both conforming hosted and conforming freestanding implementations, the Standard recognizes the use of C to write such programs as operating systems and ROM-based applications, as well as more conventional hosted applications. Beyond this two-level scheme, no additional subsetting is defined for C, since the Committee felt strongly that too many levels dilutes the effectiveness of a standard. Conforming program is thus the most tolerant of all categories, since only one conforming implementation need accept a program to rule it conforming. The primary limitation on this license is §2.1.1.3. " It turns out it's not an all-or-nothing thing. Not being "strictly conforming" is not a "breach of the contract" by the developer, and thus license for the compiler to do anything they want. See also: "Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. " http://port70.net/~nsz/c/c89/rationale/a.html http://port70.net/~nsz/c/c89/rationale/a.html
    - marcosdumay 5y ago
      It's not a contract if you can't expect one of the parties to have read it. Compiler developers do not need a contract with the users. No compiler team works with that impression. No compiler user expects one either. But if you want to use it to justify some impractical behavior, well, both your justification is a complete fabrication, and justifying it is completely meaningless. It doesn't become practical because you have some sociological theory.
- mpweiher 5y ago
  > I have always been told that, if a program contains UB, then the computer is justified in doing anything at all You have been told wrong. That's the point. 1. The C standard actually contains language that says what actions are permitted. These do not include "anything at all". 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). This was initially a binding part of the standard. Later versions of the standard still include this language, but made it non-binding. Which certain people interpreted as "the standard now says the exact opposite of what is literally in the text of the standard". 2. The C standard is and always was a compromise document, not a complete definition, in order to make it possible for the standard to be applicable to a wide variety of compilers on a very wide variety of different kinds of machines. It is thus by necessity and intention incomplete. Hence IDB and UB. That is, being compliant with the C standard is not sufficient to be useful implementation of C, something that is (or at least was) stated explicitly in the standard. This language might have been purged from newer versions of the standard, but it was there originally.
  - josephcsible 5y ago
    Why do you think "unpredictable results" doesn't mean "anything at all", especially when the sentence before that one, that you conveniently didn't quote, says UB is behavior "for which the Standard imposes no requirement"? And that's what it's said all the way since C89.
    - mpweiher 5y ago
      > Why do you think "unpredictable results" doesn't mean "anything at all" Why do you think it does?? If I roll dice, the exact number that will come up is unpredictable. However, the result will not be pink elephants parachuting through the roof. Once again, the standard then goes on to clarify what it means by "unpredictable": 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 that isn't clear enough, there is also the rationale: http://port70.net/~nsz/c/c89/rationale/a.html#1-5 http://port70.net/~nsz/c/c89/rationale/a.html#1-5 "The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe." Hmm...how can that be? Let's dig further: "Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. " Why doesn't this say "UB gives the implementor license to do anything at all"? Maybe because that wasn't the intention behind or purpose of UB? Let's dig further to "Compliance" "The three-fold definition of compliance is used to broaden the population of conforming programs and distinguish between conforming programs using a single implementation and portable conforming programs. " Hmm...according to the "standard purists", there is only one level of conformance: full conformance to the standard, everything else means the compiler can do anything it wants. Strangely, the standard itself disagrees. Let's look some more: "Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. " Again, the exact opposite of what the "standard extremists" claim. There are those who poo-pooh the idea that C is a "portable assembler". Here is what the rationale document says: "C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the Committee did not want to force programmers into writing portably, to preclude the use of C as a ``high-level assembler'': the ability to write machine-specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program" So the C standards committee explicitly sought C to be usable as a "high-level assembler". Who would have thunk? Apart from everybody who actually knows about the spirit of C. What is nonsense is this "spirit"? Well the rational says this: "The Committee kept as a major goal to preserve the traditional spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based. Some of the facets of the spirit of C can be summarized in phrases like - Trust the programmer. - Don't prevent the programmer from doing what needs to be done. - Keep the language small and simple. - Provide only one way to do an operation. - Make it fast, even if it is not guaranteed to be portable. The last proverb needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine's hardware does it rather than by a general abstract rule. " Hmm...
3836293648 5y ago
That's absolutely the contract compiler implementors are following. If you don't want to be a part of that contract you need to implement your own compiler from the ground up with optimisations based on your interpretation of UB.