Remix.run Logo
lmm a day ago

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