But undefined meant that all bets are off. It could do bizarre things including destroy the computer or make zebras fly out of the USB port. Calling through a stray pointer exhibits undefined behavior. One famous example in DOS would make the printer start spewing stuff (a failed BOUND instruction would call INT 5, if memory serves. MS decided to use that for the print-screen key instead of its intended purpose. Random garbage executed as code would hit that byte eventually.)

Since Perl 6 is more "confined" than C, I don't expect to have that very often. More usually, the implementation can choose from a range of allowed behaviors.

Sometimes, the allowed "ill-behaved" behavior is hard to pin down. For example, if you random-access a lazy list generated from a map that you promised was injective and idempotent, and the mapping block decides to return other than 1 value at some point, I can expect that list to be messed up, but the virtual machine won't crash, and strange things won't happen to global variables, etc.

—John

So, that leaves "the behaviour is unspecified" to describe the situation that you otherwise describe as "a shortcut for saying that the specification for the behavior is undefined.". Seems good to me.

---

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

That sounds right. And hangon points out that the common meaning for "behavior" is "expected behavior". So I'm really saying that the expectation is undefined.

That does seem to be how languages evolve. But when the referent is the part that got left out or left behind, it can be very annoying to more cultured ears. Like a home-improvement show says "to poly the bookcase". Er, the verb you wanted is varnish. But was "varnish" itself a noun that got turned into a verb? Apparently the word can be traced all the way back to the name of the Greek city of Κυρηναϊκή. Go figure.

It could do bizarre things including destroy the computer or make zebras fly out of the USB port.

That reminds me of a post I read in comp.std.c a long time ago:

> Now what happens if, oh, you do THIS:
>
> foo()
> {
> int x;
>
> x=10;
> if (x) free (&x);
> }
>
> I know that malloc uses heap space and that the local variables take up the
> stack, so what happens? &x is NOT null so it will try to free it, so what
> happens?

Shit happens. Exactly what shit happens depends on the implementation.
Since this is in the realm of undefined behavior a conforming implementation
is allowed to launch a pre-emptive strike against Iraq.


That was posted by Stanley Friesen on 1990-12-19, which is unfortunately older than what Google Groups has archived, so I can't give you a link to it.

Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.

I think the phrases: "the behaviour is unspecified"; or "the behaviour is implementation dependant" are more appropriate.

Not being a native English speaker I wonder - what's the difference between "unspecified" and "undefined" in that context? "undefined" means there are no specs. "unspecified" means there are no specs. What is it?

Shouldn't that be "the behavior is unpredictable" since predicting means foretelling something that will have happened at a later point in time?

Frankly, that's finickiness. 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, an analogy, a metaphor - one of those, I'm not sure which, but I guess the first is most accurate. But being such, any adjective (or adjectival component?) to express what is meant, is fine IMHO - as long as it is understood.

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

---

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

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.

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.

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.

That's what BrowserUK was originally saying.

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