07.10.2010 14:38, Bruno Medeiros wrote:
On 06/10/2010 16:59, Stanislav Blinov wrote:
I always thought that the term itself came from language specification,
i.e. the paper that *defines* behavior of the language and states that
there are cases when behavior is not defined (i.e. in terms of the
specification). From this point of view the term is understandable and,
uh, valid. It's just that it got abused with time, especially this abuse
is notable in discussions (e.g. "Don't do that, undefined behavior will
result": one can sit and guess how exactly she will get something that
is not defined).
"the term itself came from language specification" -> yes that is
correct. I read K&R's "The C Programming Language", second edition,
and the term comes from there, at least as applied to C. But they
don't define or use the term as the C FAQ above, or at least not as
explicitly, if I recall correctly (im 98% sure I am).
Now, I'm not on a solid grounds to argue (being not a native English
speaker), but the need to actually define this term seems dubious to me,
kind of another abuse if you please. The term means just exactly what it
says: the behavior [of the code/program/compiler/system/you_name_it] is
not defined, i.e. no restrictions or rules are attached to it. To me,
attempts to define undefined seem like attempts on 'adding one briefcase
into another' (from Win98 days).
They just describe each particular language rule individually and tell
you what to expect if you break the rule. Often they will say
something like "this will cause undefined behavior" and it is clear
that is is illegal.
Strictly speaking, it's not 'illegal'. If we talk about C (and we do ;)
), being a systems language, it cannot demand strict ways of handling
every situation from an implementation. Some systems may choke on
integer overflow, some may not. Some build made with single compiler may
get you useful data when addressing seemingly out-of-bounds data, yet
some builds (made with the same compiler) would grant you access
violation. (i.e. debug/release builds of MSVC).
Stating that behavior in some case is not defined, the spec leaves
implementation with a possibility to best handle that case (or, of
course, not handle it at all), or at least adapt it to some use (e.g.
for debugging), which is great for systems language, because many such
'undefined' cases can be handled very differently (in terms of
results/efficiency/whatnot) on different systems. Of course, it does not
imply that writing code that behaves in an 'undefined' manner is a good
thing to do, but being strict with what a compiler should do in all
cases is neither. Of course, replacing 'undefined behavior' with
'implementation-specific behavior' would look better, but that again
puts forward a demand (restriction) rather than possibility.
But other times they would say something like "X is undefined", where
X could be "the order of execution", "the results of Y", "the contents
of variable Z", and it is not clear whether that meant the program
could exhibit undefined behavior or not. (or in other words if that
was illegal or not)
Well, this ambiguity is hardly relating to a programming language, but
rather to natural one.
I don't know if this concept or related ones have actually been better
formalized in newer revisions of the C standard.
I don't think that "invalid behavior" covers that sense: it means that
implementation should actually do something to make code perform
'invalid' things (what should be considered invalid, by the way?),
rather than have the possibility to best adapt the behavior to system
(e.g. segfault) or some error handling mechanism (e.g. throw an
exception).
In this case I don't know for sure what the best alternative term is,
I just want to avoid confusion with "invalid behavior". I want to know
when a program execution may actually be invalidated (crash, memory
corruption, etc.), versus when it is just some particular and
*isolated* aspect of behavior that is simply "undefined", but program
execution is not invalidated. In other words, if it is illegal or not.
