5 ms·

> Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent. This pretty much is the definition of "u

> Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent. This pretty much is the definition of "undefined behaviour" in the context of a standardized language specification.

amluto 7y ago
Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware.
- AdieuToLogic 7y ago
  > Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware. That's only when using Boehm GC[0] in kernel device drivers that self-modify. Or any MSVC binary. :-D 0 - https://www.hboehm.info/gc/ https://www.hboehm.info/gc/
- AdieuToLogic 7y ago
  Whilst my other comment was intended to be jovial, it is hard to say if that was accurately conveyed. So this one will be serious. The original problem definition, as specified by @pksadiq, read thusly: > Say for example, in question 5, the statement "return i++ + ++i;" is undefined ... This inspired a response by @Filligree of: > Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent. Given the original constraint of an undefined statement result, and the suggested activity to address same, I posited that the recommended action is an exemplar of observing the product of undefined behaviour. You then contributed: > You mean “unspecified behavior”. As per c-faq.com[0], there are three categories identified relating to this topic: 1 - implementation-defined: The implementation must pick some behavior; it may not fail to compile the program. 2 - unspecified: Like implementation-defined, except that the choice need not be documented. 3 - undefined: Anything at all can happen; the Standard imposes no requirements. Whereas you imply a standards-conformant implementation of "return i++ + ++i;" is unspecified (category #2), it is, in fact, undefined (category #3). The support for this assertion is as follows. As per the same site, Question 3.8[1] includes: > Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. And further states: > ... if an object is written to within a full expression, any and all accesses to it within the same expression must be directly involved in the computation of the value to be written. This rule effectively constrains legal expressions to those in which the accesses demonstrably precede the modification. And concludes with an example stating: > ... the Standard declares that it is undefined, and that portable programs simply must not use such constructs. Therefore, the original expression presented by @pksadiq is in fact an exemplar of an undefined expression as defined by category #3 shown above. Since both it and the message to which I originally responded satisfy same, I stand by my response given to @Filligree as having had informally defined the standard C concept of "undefined behaviour." 0 - http://c-faq.com/ansi/undef.html http://c-faq.com/ansi/undef.html 1 - http://c-faq.com/expr/seqpoints.html http://c-faq.com/expr/seqpoints.html
  - Dylan16807 7y ago
    > Whereas you imply a standards-conformant implementation of "return i++ + ++i;" is unspecified (category #2), it is, in fact, undefined (category #3). You're misreading things. amluto's assertion is that "The answer will vary from place to place, but it isn't non-existent." is a description of category #2. That assertion is basically correct, depending on how exactly you define "place to place". An informal definition of category #3 is "The answer can vary from place to place, or not exist at all." ideally followed by "It might crash or run unrelated code or even prevent the preceding code from running." It's flat-out wrong to say a value "isn't non-existent" when it comes to source code exhibiting undefined behavior.

amluto 7y ago

Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware.

AdieuToLogic 7y ago
> Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware. That's only when using Boehm GC[0] in kernel device drivers that self-modify. Or any MSVC binary. :-D 0 - https://www.hboehm.info/gc/ https://www.hboehm.info/gc/
AdieuToLogic 7y ago
Whilst my other comment was intended to be jovial, it is hard to say if that was accurately conveyed. So this one will be serious. The original problem definition, as specified by @pksadiq, read thusly: > Say for example, in question 5, the statement "return i++ + ++i;" is undefined ... This inspired a response by @Filligree of: > Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent. Given the original constraint of an undefined statement result, and the suggested activity to address same, I posited that the recommended action is an exemplar of observing the product of undefined behaviour. You then contributed: > You mean “unspecified behavior”. As per c-faq.com[0], there are three categories identified relating to this topic: 1 - implementation-defined: The implementation must pick some behavior; it may not fail to compile the program. 2 - unspecified: Like implementation-defined, except that the choice need not be documented. 3 - undefined: Anything at all can happen; the Standard imposes no requirements. Whereas you imply a standards-conformant implementation of "return i++ + ++i;" is unspecified (category #2), it is, in fact, undefined (category #3). The support for this assertion is as follows. As per the same site, Question 3.8[1] includes: > Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. And further states: > ... if an object is written to within a full expression, any and all accesses to it within the same expression must be directly involved in the computation of the value to be written. This rule effectively constrains legal expressions to those in which the accesses demonstrably precede the modification. And concludes with an example stating: > ... the Standard declares that it is undefined, and that portable programs simply must not use such constructs. Therefore, the original expression presented by @pksadiq is in fact an exemplar of an undefined expression as defined by category #3 shown above. Since both it and the message to which I originally responded satisfy same, I stand by my response given to @Filligree as having had informally defined the standard C concept of "undefined behaviour." 0 - http://c-faq.com/ansi/undef.html http://c-faq.com/ansi/undef.html 1 - http://c-faq.com/expr/seqpoints.html http://c-faq.com/expr/seqpoints.html
- Dylan16807 7y ago
  > Whereas you imply a standards-conformant implementation of "return i++ + ++i;" is unspecified (category #2), it is, in fact, undefined (category #3). You're misreading things. amluto's assertion is that "The answer will vary from place to place, but it isn't non-existent." is a description of category #2. That assertion is basically correct, depending on how exactly you define "place to place". An informal definition of category #3 is "The answer can vary from place to place, or not exist at all." ideally followed by "It might crash or run unrelated code or even prevent the preceding code from running." It's flat-out wrong to say a value "isn't non-existent" when it comes to source code exhibiting undefined behavior.