You can predict unspecified behavior: it gives a range of possibilities which do not include failures like termination, or data corruption.

The order of evaluation of function arguments in C is unspecified, so every time any function whatsoever is called which has two or more arguments, there is unspecified behavior.

Same in Scheme!

A security flaw can be caused by a bug that is built on nothing but 100% specified constructs.

The construct with unspecified behavior won't in and of itself cause a security problem. The programmer believing that a particular behavior will occur, whereas a different one occurs, can cause a bug.

The unspecified behaviors of a hash table in the face of modified keys can be spelled out in some detail.

Example requirements:

"If a key present in a hash table is modified to an unequal value, it is unspecified whether the entry can be found using the new key; in any case, the entry cannot be found using the old key. If a key present in a hash table is modified to be equal to another key also present in the same hash table, it is unspecified which entry is found using that key. Modification of a key doesn't prevent that key's entry from being visited during a traversal of the hash."

▲

lmm a day ago | parent [-]

> The order of evaluation of function arguments in C is unspecified, so every time any function whatsoever is called which has two or more arguments, there is unspecified behavior.

Yes, and that's bad! Subsequent languages like Java learned from this mistake.

> A security flaw can be caused by a bug that is built on nothing but 100% specified constructs.

Of course. But it's less common.

> The programmer believing that a particular behavior will occur, whereas a different one occurs, can cause a bug.

And unspecified behaviour is a major cause of this! Something like Hyrum's Law applies; programmers often believe that a thing will behave the way it did when they tested it.

> The unspecified behaviors of a hash table in the face of modified keys can be spelled out in some detail.

That is to say, specified :P. The more you narrow the scope of what is unspecified, the better, yes; and narrowing it to nothing at all is best.

▲

kazinator 14 hours ago | parent [-]

I'm a big opponent of unspecified argument evaluation order, but my point was more that the sky doesn't fall because of that.

Though it's pretty ridiculous that a mainstream Lisp dialect is that way, of all things.

	▲	lmm 13 hours ago \| parent [-]
		> the sky doesn't fall because of that. No, especially in a language like C that has much bigger problems (I don't think there's ever been a nontrivial C program that has defined behaviour according to the standard), but it's one more papercut. > Though it's pretty ridiculous that a mainstream Lisp dialect is that way, of all things. I don't think I'd call any Lisp dialect "mainstream".