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

[Pétur Runólfsson]

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.

>> 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.

> 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.

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?

Petur