> just document that the behavior becomes unspecified if keys are mutated while they are in the table.

> Make sure the behavior is safe: it won't crash or be exploitable by a remote attacker.

There is no such thing as unspecified but safe behaviour. Developers who can't predict what will happen will make invalid assumptions which will lead to security vulnerabilities when they are violated.

▲

kazinator a day ago | parent [-]

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