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

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Wed, Jul 09, 2003 at 10:09:41AM -0000, P?tur Run?lfsson wrote:
> Nathan Myers wrote:
> > The type safety argument dictates that we should use a class type
> > for std::streamoff containing a 64-bit integer type,
> 
> I agree.
> 
> > and publicly defining (only!) the operations required in 27.4.3.2,
> 
> Those operations seem to be conversion to and from streamsize and
> fpos<StateT>, and arithmetic involving fpos<StateT>. That seems
> very restrictive. Shouldn't there at least be support for 
> 
> +m, -m, ++m, m++, --m, m--, m + n, m - n, m += n, m -= n,
> m > n, m >= n, m < n, m <= n, m == n, m != n
> 
> on streamoff objects m and n?

No.  Any operations not listed in the table are not portable.  We 
don't have any access to the "-pedantic" flag to help users ensure 
that operations they use are portable.  The danger in not supporting 
them directly is mainly that they might occur via implicit conversions 
to and from int or streamsize.  Note that the conversion to streamsize 
(a built-in integer type) is necessarily implicit, and so is the 
conversion from int to fpos<>.

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.

Note that this is something we should do, and should have done,
regardless of 64-bit support.

> > Internally we can use undocumented members to extract and set the
> > 64-bit value for use with lseek64 or what have you.
> 
> traits_type::off_type doesn't need to be streamoff, the behaviour is
> implementation defined if it isn't, so it seems those members would
> need to be documented.

OK, I agree.  

> There must be a simple way to construct streamoff from 64-bit
> integers, also on platforms on which streamsize is 32 bits; otherwise
> it will be impossible to actually use the large file support.
> 
> Example: Seeking to a point 60GB from the beginning of the file:
> 
> filebuf fb;
> ...
> long long GB = 1000000000LL;
> 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?  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.

We are allowed to overload pubseekoff, and streamoff constructors, in any 
way that a conforming program (i.e. one that uses only standard language
features, headers, and names) cannot detect.

Nathan Myers
ncm-nospam@cantrip.org