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
