Re: module level flags

[Joe Buck <jbuck at synopsys dot com>]

> > At least in the case where the bad code is always reached if the
> > function is called, a hard error might be reasonable.

Alexandre Oliva writes:
> Nope.  Consider a function that would only be called with arguments
> that were known not to run into any aliasing problems.  When the
> compiler can't tell, it is required to translate the code.

You possibly misunderstand.  I was ony suggesting a hard error for a case
that would invoke undefined behavior for *any* choice of arguments.

That is, for any analysis question that runs into the halting problem,
or is just too complex to solve, one can write a heuristic that gives
a three-way answer: always an error, never an error, or "can't tell".
But there are plenty of "always an error" cases, where you can tell
by inspection that an object is accessed with the wrong type.

My suggestion was that in cases that are always an error (assuming that
the function gets called at all), we might as well issue a hard error.
"But the function might never be called", you reply.  So what?  In
principle the compiler could replace the whole function by abort(),
but I see no practical (as opposed to pedantic) reason why issuing a hard
error in such cases is not allowed.