4 ms·

> 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 e

by lmm 1y ago

> 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 1y ago
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 1y 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 1y ago
    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 1y ago
      > 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".
      - kazinator 1y ago
        Regarding that last bit; yes, that's a kind of contextual phraseology used by Lisp people sometimes in reference to the major Lisps. Among the "streams" in the Lisp landscape, those are the main ones.
  - deleted 1y ago
    [deleted]

by lmm 1y ago

kazinator 1y ago

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 1y 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 1y ago
  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 1y ago
    > 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".
    - kazinator 1y ago
      Regarding that last bit; yes, that's a kind of contextual phraseology used by Lisp people sometimes in reference to the major Lisps. Among the "streams" in the Lisp landscape, those are the main ones.
- deleted 1y ago
  [deleted]