On C/C++ undefined behaviours (on the term "undefined behaviours")

Bruno Medeiros brunodomedeiros+spam at com.gmail
Fri Oct 8 05:17:05 PDT 2010


I'm gonna summarize this up in two points:

A) We should define certain terms within the D language in a precise 
way, to help us communicate with each other more clearly, both in 
discussion as well as in documents and specifications.

B) We should strive that the way we define such terms be the best we can 
make it, in order to avoid ambiguity and confusion with other terms, and 
with natural language itself.
(just as there is good code and bad code, there could also be good and 
bad term definitions)


I googled a bit more, and actually found that D (even as far as D1) does 
indeed formally define "Undefined behavior", in an equivalent way as the 
C FAQ:

http://www.digitalmars.com/d/1.0/glossary.html
""
UB (Undefined Behavior)
     Undefined behavior happens when an illegal code construct is 
executed. Undefined behavior can include random, erratic results, 
crashes, faulting, etc.
""

And from TDPL, section 12.2.1:
""
Undefined behavior: The effect of executing a program fragment in a 
given state is not defined. This means that anything within the realm of 
physical possibility could happen.
""

This is good, it means we get (A). I don't think we have (B) though, I 
think the name of the term could be better, as I discussed in the 
previous posts.
Now that I know we have (A), I actually don't want to spent more time 
arguing (B) either, but I am gonna "police" the forums because I'm sure 
this terms has been used, and will be used again not according to the 
definition.

-- 
Bruno Medeiros - Software Engineer


More information about the Digitalmars-d mailing list