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

[Bruno Medeiros]

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