This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: basic VRP min/max range overflow question
fw@deneb.enyo.de (Florian Weimer) wrote on 18.06.05 in <87oea3gz29.fsf@deneb.enyo.de>:
> * Paul Schlie:
>
> > So in effect the standard committee have chosen to allow any program which
> > invokes any undefined behavior to behave arbitrarily without diagnosis?
> >
> > This is a good thing?
>
> It's the way things are. There isn't a real market for
> bounds-checking C compilers, for example, which offer well-defined
> semantics even for completely botched pointer arithmetic and pointer
> dereference.
>
> C isn't a programming language which protects its own abstractions
> (unlike Java, or certain Ada or Common Lisp subsets), and C never was
> intended to work this way. Consequently, the committee was right to
> deal with undefined behavior in the way it did. Otherwise, the
> industry would have adopted C as we know it, and the ISO C standard
> would have had the same relevance as, say, the ISO Pascal on the
> evolution of Pascal.
And yet, languages like ISO Pascal *still* define undefined behaviour
pretty much the same way C does. They just choose a different set of
situations (well, there *is* overlap) to apply it to.
Pretty much all languages which allow access to "the bare metal" need this
escape clause, because making a program safe in that context pretty much
requires the compiler to solve the halting problem or equivalent - and we
can't do that. The alternative is putting enough padding between the
program and the metal to enable the compiler and runtime system
significantly more control - and, of course, giving the programmer
significantly *less* control. For example, there won't be any type-punning
in such a language. It's a very different trade-off.
MfG Kai