[Patch] Fix libstdc++/11378 (take2) + xsputn optmizations

[Nathan Myers]

On Wed, Jul 09, 2003 at 07:21:48PM -0000, P?tur Run?lfsson wrote:
> Nathan Myers wrote:
> > We can provide overloaded operators in an ext/ header to perform 
> > the operations listed above.  Probably we should declare but not
> > define them in the regular header, to prevent them occurring via 
> > those implicit (and lossy) conversions.
> 
> Since streamoff has an implicit conversion to streamsize, streamsize
> is a built-in integer type, and streamoff can be constructed from
> streamsize,
> 
> #include <ios>
> int main()
> {
>   std::streamoff m, n;
>   std::streamoff o(m - n);
> }
> 
> is a conforming program. I don't think it's acceptable to evaluate
> m - n using 64-bit arithmetic if a particular header has been
> included (possibly indirectly), otherwise 32-bit. It's hardly
> acceptable either to always use 32-bit; since this program
> compiles, it should work. The same applies more or less if either
> of m or n is an integer type.

Uh-oh.  If it's a conforming program, then adding overloads that make
it _not_ truncate its result is not allowed.  That looks like a defect.
(Somebody needs to file a defect report.)  I don't think we should try 
to preserve defective behavior.  At issue is what to do instead: 
silently "do the right thing" (non-portably, and in violation of 
standard requirements) or issue an error message that gives a clue 
on how to do it right (also non-conforming, and non-portable, but 
explicit).  I prefer the latter.

> >> fb.pubseekoff(60 * GB, ios::beg);
> >> 
> >> Shouldn't this work?
> >
> > Would you consider silently truncating the 60G value to 32 bits to be 
> > reasonable behavior?
> 
> No, but not surprising either (it's what happens on gcc 3.3). On a
> platform that claims large file support it is hardly acceptable.

Agreed.

> > It's what would happen on most existing
> > implementations.  I'd rather get an error message -- a link error, if 
> > necessary, ultimately directing me to a comment in the relevant header 
> > that explains how to evoke the non-portable behavior explicitly.
> 
> This will fail to compile if streamoff has a private, undefined
> constructor for each integer type that is larger than streamsize -
> and the error message will include the line in the header where the
> constructor is declared.

OK.  Then, it needs constructors for *all* numeric types, because
standard conversions won't be applied, and 

  fb.pubseekoff(short(60), ios::beg);
  
would fail.

> However, this program is already non-portable - it uses the
> non-standard type long long int. Is there any real value in making
> it not compile?

The "long long" type has quasi-standard status.  It's a shoo-in for
C++-0x, and is in C99 already.  It would be a grave error to do something 
that differs from what the standard will say, whatever that turns out 
to be.

Nathan Myers
ncm-nospam@cantrip.org