Conversation

Notices

1. awavauatush (ninjawedding@sdfn-01.ninjawedding.org)'s status on Thursday, 01-Feb-2018 17:33:47 EST awavauatush
   "unspecified behavior": "the behavior of this construct may vary across implementations but will conform to at least these guarantees"
   "undefined behavior": "idk lol ¯\_(ツ)_/¯ rm -rf /"
   1. awavauatush (ninjawedding@sdfn-01.ninjawedding.org)'s status on Thursday, 01-Feb-2018 19:03:54 EST awavauatush

      in reply to
      Oh thanks
   2. Verius (verius@community.highlandarrow.com)'s status on Friday, 02-Feb-2018 13:34:39 EST Verius

      in reply to
      @ninjawedding I've found a good way to reason about Undefined Behavior is that it's stuff that's incorrect but expensive in terms of performance to require a compiler to detect. For example to define null pointer derefences you actually would need to insert a check everywhere a pointer could be null. You can't just say "this crashes the program" since the C language spec doesn't actually mandate the behavior of the processor and OS (you can't force every OS to have a non-accessible page 0 and in deeply embedded situations you will want to use that page (or won't have virtual memory / page protection bits)). Meanwhile a compiler can do some useful tricks if it can know a pointer won't be dereferenced (since that would be a bug by the programmer). Same with strict aliasing, it allows the compiler to assume two pointers won't point to the same location and that has important effects on possible optimizations.