On 07/10/2010 12:47, Stanislav Blinov wrote:
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).
In the context of natural language, the term means exactly what it
means, yes. But in the context of a particular programming language, we
often give more precise meanings to certain natural language terms,
because it is very useful and important. For example "object",
"contract", "exception", "thread", "valid/invalid code", and many
others. Without these terms it would be very complicated to communicate.
"undefined behavior" was not given a precise meaning in K&R TCPL, but it
is given a much more precise and stricter meaning in the C FAQ and the
original article. These meanings look similar but they are slightly and
critically different. And this ambiguity percolates through the C community.
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.
No, it is illegal behavior according to what I meant by "illegal
behavior". :)
You thought otherwise because you likely had a slightly different idea
of what I meant by "illegal". And this is precisely my point, if you
don't precisely define the terms, communication is harder and
misunderstandings happen.
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.
Yes, there is sometimes ambiguity in the natural language. That's why we
have to be thoughful in how we define our terms in the context of
programming languages. We want to reduce natural language ambiguities to
a minimum.
--
Bruno Medeiros - Software Engineer
