[Patch] Fix libstdc++/9659

[Nathan Myers]

On Tue, Feb 11, 2003 at 04:35:58PM +0100, Paolo Carlini wrote:
> Nathan Myers wrote:
> 
> >This looks to me like a grave compiler bug.  
> Indeed, naively, seems weird that, being operator+ defined inside fpos 
> besides operator+=, an user of pos_type cannot use that syntax.
> 
> Could you please explain in a little more techincal detail what seems 
> wrong with the compiler?

Looking at the affected code in more detail...

  __ret = __tmp + std::max(this->_M_out_cur, this->_M_in_cur) - _M_filepos;

The type of _M_filepos is _CharT* (b)
The type of __tmp is long or long long (c)
The type of _M_*_cur is _CharT* (d)

  a = b + c - d;
  a = (b + c) - d;
  a = b + (c - d);

Depending on how the compiler chooses to group these, we have an
integral type added to a pointer, and then another pointer subtracted
from it, yielding ptrdiff_t; or an integral type added to a pointer
difference.  Whether the result is defined depends on whether b + c
is within the array pointed to by c.

Splitting the statement in two, as Paolo did, ensures that the
third form above is what is computed.  I believe that adding 
parentheses should suffice, but Paolo's suggestion makes the 
grouping clearest.

I withdraw my objection to Paolo's patch.  

I think it's a compiler bug that it rejects the code at one -O
level and accepts it at another, particular since the difference
is in overload resolution.

Nathan Myers
ncm-nospam@cantrip.org