4 ms·

If you extend "unspecified" to allow traps, reading a bogus pointer can also be unspecified, only writes undefined in the current sense.

• Karellen 4y ago
  I don't think so. With "unspecified" and "implementation-defiend" behaviours, the implementation has to pick a behaviour and be consistent with it. The difference is whether they have to document that behaviour or not. If the hardware traps on bogus pointers, then reading a bogus pointer may trap. But if you read a recently-freed pointer, it may still be valid according to the hardware (e.g. will have valid PTEs into the processes address space) so won't trap. Therefore you won't be able to guarantee any particular behaviour on an invalid read, so I don't think you'd be able to get away with "unspecified" or "implementation defined" behaviour on most hardware.
  • owl57 4y ago
    AFAIR reading uninitialized int, for example, is "unspecified" (any value could be there). If we consider adding "implementation defined with possible trap" for overflow, we might as well add "unspecified with possible trap" for reading an invalid pointer (any value could be there, or it could trap, but no nasal demons).
    • temac 4y ago
      Using unitialized values is UB. Going back to naive pointers is a lost cause because compilers have started to do crazy optims (not even currently allowed by the standards...) like origin analysis. You can't steal that toy from the people implementing optims.