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 it remains unspecified.

Once you can create circumstances for which the specification does not define the expected effect, outcome or result, you can then see what actually happens. And once you know what actually happens, it is no longer undefined; just unspecified.

It is actually very rare that for any given set of circumstances, a computer program will result in a random outcome. In general, for a given set of inputs, you will get the same set of outputs/outcomes. Were that not the case, the whole basis of testing and test driven development wouldn't work. It is the very basis of debugging--hence the maintainers plea for minimum reproducible testcases. It's not always easy to determine the full input set, but they're the bugs that are most interesting--provided time pressure isn't too high.

Hence, it is usually possible to say that for build X of Y; doing Z will result in A. Even though it may not be specified; and that it might change with platform, implementation or build; and as such, should not be relied upon.

What's that talking of "behavior" concerning computers, anyways? There's no such thing. Computers don't "behave", since they don't choose one reaction or another out of a set of possibilities at free (or bound) will, pondering the effect of that choice. Talking of "behavior" when it comes to computers is an anthropomorphism,

Using the word behaviour in conjunction with computers is not anthropomorphising. Behavour can be simply defined as "the actions or reactions of an object or organism".

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.

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

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.

Even if you can determine what's happening from a finite number of runs, all you can do is study the behaviour of existing implementations.

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

You find their meaning to be the same because you automatically assume "behavior is undefined" to "the documentation for this behavior is undefined". Some would say that this is indeed implied by context, since the entire document is referring to "the behavior" in some kind of weird literary timeless tense or imperfect tense.

But, I'm against evolving language out of stupidity or laziness. That is, don't misuse words if there is already a good and proper way to say it. If there isn't, then I'll consider it.

FWIW, doing bad things in Perl shouldn't be undefined to the same extent as C. The ill-effects should be bounded and the larger context fault tolerant. But specifying that in detail makes it legal and well-defined!

—John