Darren New <dne### [at] sanrrcom> wrote:
> > If you dereference null, *anything*
> > can happen (including the following code doing something completely different
> > than what you expect).

> And it's not just dereferencing null. It's any of the undefined behaviors 
> which can lead to the compiler doing very unintuitive things if you're not 
> aware of the rule.

  OTOH "undefined behavior" also allows for the compiler to, for example,
add sanity checks and issue clear runtime errors when these kinds of errors
happen.

  Some compilers actually do this with a bunch of undefined behavior
situations when compiling in debug mode. However, it's a rather curiously
rare thing to do. I have been wondering why C/C++ compilers don't have a
"super-debug mode" where *everything* that can possibly go wrong is checked
(if it can be physically checked), completely regardless of how slow the
program becomes. A bit like a "builtin valgrind" (but which adds even more
checks which the compiler can do because it can see the source code). Only
few C/C++ compilers have anything even resembling this, and usually in a
relatively limited form (ie. the debugging mode doesn't even do all the
same checks as valgrind does).

  Maybe it's a question of complexity vs. demand, or something.

-- 
                                                          - Warp

Post a reply to this message