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

[Stanislav Blinov]

  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.
>
>