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
- From: Paul Schlie <schlie at comcast dot net>
- To: Robert Dewar <dewar at adacore dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>,Dale Johannesen <dalej at apple dot com>,Mike Stump <mrs at apple dot com>,Andrew Pinski <pinskia at physics dot uc dot edu>,GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 20 Jun 2005 07:26:01 -0400
- Subject: Re: basic VRP min/max range overflow question
> From: Robert Dewar <dewar@adacore.com>
> Robert Dewar wrote:
>
>> That may be your position, but it is not the position of the standard, and
>> indeed it is not a well-formed position. Why, because the whole point is
>> that
>> when the behavior is undefined, then the change DOES yield a logically
>> equivalent behavior, because undefined means undefined, and all possible
>> behaviors are logicaly equivalent to undefined.
>
> To add to this, I can see how you might feel that even if the standard
> allows this behavior it is non-desirable, but I don't even agree with that.
> The trouble is if the compiler makes this "work", then C programmers who
> don't really know the language end up depending on it, and writing what
> is essentially junk non-portable code. It is a GOOD THING if C programmers
> are burned by this and learn the language. It is perfectly possible to
> write portable programs in C, but you have to know the language to do it,
> and knowing the language means knowing what the actual rules are, not just
> being familiar with the behavior of a particular compiler.
I too believe I understand your position, however don't believe it's the
compiler's job to make life for the programmer harder than it need be when
a program may contain an undefined behavior; but agree it would likely
always be helpful to for it to point them out when identifiable.