Re: PR 25512: pointer overflow defined?

[Robert Dewar <dewar at adacore dot com>]

Gabriel Dos Reis wrote:

> with no more qualifications (this definition is slightly different in
> some nearby languages), it is slippery to found optimizations on
> "pointer overflows."
>  
Well I think unfortunately the standard does allow such "optimizations", 
but that does
not mean it is a good thing to take advantage of this.

> And even more so, the existing practice in widely used programs is to
> compare pointers to things like (void *)-1.  And this even in GCC own
> source code.
>  
Indeed! And as I said in an earlier message, I think gcc is far too 
ready to hide
bad behavior behind the justification of wording in the standard. When 
things
are undefined, there is every argument for doing what people expect and what
will cause least surprise, unless a *VERY* strong argument is made that an
optimization is really important. Since almost no individual optimizations
are in themselves really important, this is a very hard burden to meet.

We had a similar case in GNAT recently:

  X : Xtype;

  ...

 if X in Xtype then

The Ada standard clearly justifies removing this test, but equally 
clearly the user
is doing this for a reason, and the likely reason is almost certainly 
that a test is
wanted for the representation of X being in range of its type (e.g. after an
unchecked conversion).

GCC 3.4 optimization did indeed remove this test, due to over-enthusiastic
treatment of range information, and many users complained. So we changed
GNAT to treat this case as:

  if X'Valid then

and issue a warning

(I still don't think that's good enough, it catches only some cases, and 
for example,
if X > Xtype'Last
will still malfunction. I would like to just eliminate this range 
optimization for
Ada, I just don't believe it is worth the aggravation of expectations).

My favorite example of hiding behind the standard is that Fortran 66 
carefully
allowed either stack or static allocation of local variables. All Fortran
compilers did static allocation, and most (almost all) Fortran programs
relied on this. Burroughs 5500 Fortran translated into Algol-60 (the only
assembly language for the machine, there was no separate assembler),
and used stack allocation. Frightfully standard, but completely useless,
and Burroughs lost sales because of the failure of its Fortran compiler
to compile and run standard Fortran codes.

So please don't take my comments as supporting dubious optimizations
of pointer arithmetic.

For me the only practical acceptable implementation of pointers in C
is to use lineary addresses as integers, and implemnet wrap around
arithmetic on these values.