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.

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

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

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.

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

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.

And once you know what actually happens, it is no longer undefined; just unspecified.

Thanks, got that. I' still not sure about "behavior", but that might come from my German (and Spanish) background where "behavior := Verhalten" which is related (!) to "Verhältnis := relationship". I think "behavior" more in terms of "comportment", e.g "behave yourself!", "¡compórtate!", which is beyond mere mechanics.

Unfortunately, my language skills barely allow me to cope with my native tongue--my attempts at other langauges have mostly either been humorous or a disaster--so I cannot offer you its etymology.

I googled for define:behaviour. The first definition listed is:

behavior: the action or reaction of something (as a machine or substance) under specified circumstances;

. "Well behaved handling" can be applied to cars, motorcycles, aircraft...

Behaviour is also not confined to use with concrete things like machines and people; it's not uncommon in our industry to talk of "well behaved algorithms"; and chemists talk of "well behaved reactions".

---

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

So, perhaps you can propose some words to use. I'm for using less common words to give a formal meaning when the common words are already meaningful to the reader or may be used casually within the explanations.
• Behavior, or what the spec is defining in the first place. This really has two depths to it. The running program is defined by its side effects and the order in which they occur. Within the program, language constructs have meaning based on what came before, so behavior can include setting up certain data structures and so on.
• Sometimes the implementor can choose between a few reasonable alternatives, like using signed or unsigned logic, or the length of something.
• The implementor must complete the specification here, and choose something that is well-behaved and repeatable and doesn't interfere with anything else. It's not wrong to do that, but the result is "implementation dependent".
• It's really bad to do that, and doing so may cause the rest of the specification to no longer hold. That's "undefined behavior".
• Containment and correction -- if "really bad" is defined in terms of the spec no longer holding, you can instead define other changes to the system, e.g. a variable is now something else, and then get back on the rails in terms of the specification holding under the modified state.

The difference is that after the fact--ie. once the program is implemented and you can try a scenario and see empirically what happens--what happens is no longer undefined.

But the phrase the behaviour is undefined is much stronger than that. It says something about any other possible implementation; specifically, it says that you cannot determine the behaviour of a particular implementation by looking at other implementations.

And don't come with "but there's only one implementation of [Pp]erl". There isn't. 5.10.0 differs from 5.8.9. And 5.10.1 will differ from 5.10.0. Even 5.10.0 build with options X, Y, and Z on platform W will differ from 5.10.0 build with options A, B, C on platform D.

But the phrase the behaviour is undefined is much stronger than that.

I understand what it is intended to mean; but it fails in that intent. Please see Re^5: The behavior is [sic] undefined.

Once an implementation exists its behaviour is defined--by the implementation itself. And the behaviour of all implementations is defined by their implementations. Those behaviours that are unspecified may differ between implementations, but they are defined.

---

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