Re^4: The behavior is [sic] undefined

What you get by executing the code and recording empirical evidence is more a description than a definition. I agree with most of your reasoning here about "undefined behavior" being an obtuse idiom, but I can see counterarguments which support its use. Let me present those.

A prescriptivist will tell you that once a term is defined that the definition can't change. Something that is unspecified and that is referred to as an "undefined" combination of language features is expected to be allowed to change, even within the same project's different versions.

By saying you have "defined" it, you're effectively saying that you've found out what it should do rather than what id did do. That's not the intent, I think, of the term "undefined behavior". An "undefined behavior" as the term is used is one that may be different in a different implementation, on a different platform, or in next week's release. It is both unspecified and the empirical result, while often possible to ascertain, is not to be taken as definitive. If there is no definitive semantic, then the construct is undefined.

The term "undefined" means whatever it is describing defies a fixed meaning. Looking at Webster's, we can see several definitions of "define". An "undefined behavior", as the term is used, is one that the specification has not, according to definition 1a, determined the essential qualities or meaning of the construct or its behavior. The spec has not, according to 1b, set "forth the meaning" for further implementations. Definition 1c is ironically not applicable despite mentioning computers. According to 2a, to define can mean "to demarcate" or "to fix the limits of" something, and your empirical tests of one implementation do not fix any limits on others as only the specification can. Under any of these definitions of "define", a behavior marked in a specification as "undefined" has not been defined by observation of results in an implementation. Perhaps it has been connoted, but not defined.

So perhaps the term shouldn't be used because it is difficult for some to understand, but I don't think it's actually that far from a correct usage. Any combination of language features that together do not have a fixed meaning could be said to remain undefined.

Comment on Re^4: The behavior is [sic] undefined

Replies are listed 'Best First'.
Re^5: The behavior is [sic] undefined by BrowserUk (Patriarch) on May 15, 2009 at 06:28 UTC
I'm sorry to do this to you, but a lot of of what you wrote just doesn't make any sense at all. once a term is defined that the definition can't change. What "term"? We're talking about defining behaviour--or rather not defining it. Unless you are talking about the term 'undefined behaviour', in which case I would tell the prescriptivist that I have no desire to change the definition of that term--there's no point because it is nonsensical. I'm attempting to persuade perlers to adopt a term for the situations where perl's behaviour is deliberately left unspecified, that actually describes those situations; 'Unspecified behaviour' seems to fit rather nicely. Something that is unspecified and that is referred to as an "undefined" combination of language features How could you possibly specify the behaviour of "an undefined combination of language features"? The best you could possibly do in this vein is to specify the behaviour of every possible legal combination of language features--and then say anything else is illegal and its behaviour is thus unspecified. And combinatorics says that is improbable if not impossible. ... is expected to be allowed to change, even within the same project's different versions. Of course. I acknowledged that above. By saying you have "defined" it, you're effectively saying that you've found out what it should do rather than what id did do. But no. That's like saying that discovering that eating peanuts makes you ill, means that anyone eating peanuts will become ill. Defining (to describe, explain, or make definite and clear), what happens for a particular instance does not imply defining for all instances. On the other hand, specifying what should happen, by implication does apply to all instances. And if, when a particular instance's behaviour is defined--through observervation, measurement or testing--it is found to differ from the specification, then it can be said to be exhibiting unspecified behaviour, but not undefined behaviour. That's not the intent, I think, of the term "undefined behavior". An "undefined behavior" as the term is used is one that may be different in a different implementation, on a different platform, or in next week's release. It is both unspecified and the empirical result, while often possible to ascertain, is not to be taken as definitive. If there is no definitive semantic, then the construct is undefined. I understand the intent. I'm saying that the term "undefined behavior" does not meet that intent. And that's my bottom line. The term can only be understood to mean its intended meaning, if you have previously encountered it and have rote learnt to interpret that particular combination of those two words, when used in the specifications for a computer language, to mean that intended meaning. There is no way to arrive at that interpretation through logical analysis of the juxtaposition of the two words themselves. Even in context. That precludes anyone making their first encounter with the term from understanding it, which is devisive. I see no sense in continuing to perpetuate a nonsensical phrase, that was wrong the first time it was written, just because it has been replicated in the interim without challenge. Especially when there are other, better, phrases that can be used. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^6: The behavior is [sic] undefined by gwadej (Chaplain) on May 15, 2009 at 13:17 UTC
And that's my bottom line. The term can only be understood to mean its intended meaning, if you have previously encountered it and have rote learnt to interpret that particular combination of those two words, when used in the specifications for a computer language, to mean that intended meaning. There is no way to arrive at that interpretation through logical analysis of the juxtaposition of the two words themselves. Even in context. Which is basically the definition of an idiom. Most natural languages would be poorer if we discarded every expression (idiom) that matches your description. G. Wade	[reply]
Re^6: The behavior is [sic] undefined by mr_mischief (Monsignor) on May 15, 2009 at 15:40 UTC
What do you mean, "what term"? We're talking about the semantics of a combination of language features to be unspecified or undefined. That expression in that language is the "term". That's why it's called a language. The syntax has semantics -- the expressions have meaning. An expression that is "undefined" has no accepted meaning. I think you're stretching a bit to arrive at your stated premise. Perhaps my understanding of "behavior" and "undefined" by themselves differ from yours, because I never had a problem understanding that "undefined behavior" meant there was no prescriptive meaning assigned to a certain syntactical construct. I didn't have to learn it by rote, and it was clearly logical to me. As I said before, though, if you find it too idiomatic to be useful, then don't use it. Just don't assume that because you say it can't be understood without a glossary that people will accept that statement based on you making it.	[reply]
Re^6: The behavior is [sic] undefined by John M. Dlugosz (Monsignor) on May 15, 2009 at 17:36 UTC
And that's my bottom line. The term can only be understood to mean its intended meaning, if you have previously encountered it and have rote learnt to interpret that particular combination of those two words, when used in the specifications for a computer language, to mean that intended meaning. There is no way to arrive at that interpretation through logical analysis of the juxtaposition of the two words themselves. Even in context. So a well-thought-out unified standards document would not have that problem at least, since it opens with a set of statements saying what is meant by certain terms including this one, and refers up to parent standards' body mandated usage for some things too. Ad-hoc documentation cobbled together without any formalism will suffer from "must be clear from this context only," but a uniform document does not. Every usage for a formal term could be hyperlinked to its definition, perhaps. There is no way to arrive at that interpretation through logical analysis of the juxtaposition of the two words themselves. Even in context. I do beg to differ on this point. Others have chimed in and said that "behavior" is assumed to mean "specification of behavior", and that is the entire context of the document. —John	[reply]
Re^7: The behavior is [sic] undefined by BrowserUk (Patriarch) on May 16, 2009 at 22:46 UTC
"behavior" is assumed to mean "specification of behavior" Which absolutely confirms that: "There is no way to arrive at that interpretation through logical analysis of the juxtaposition of the two words themselves.". Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^5: The behavior is [sic] undefined by John M. Dlugosz (Monsignor) on May 15, 2009 at 16:46 UTC
I'm sorry to do this to you, but a lot of of what you wrote just doesn't make any sense at all. But for some other stuff, I like where you're going with it. Think about being in a prescriptive setting. Connoted but not defined. I'm big on docs to separate defined behavior from incidental behavior. Calling the observation something other than "defined", as being done for referenced posts talking about a language "defined" by its one implementation, is something I like.	[reply]