This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] Fix libstdc++/11378 (take2) + xsputn optmizations
On Tue, Jul 08, 2003 at 10:01:40PM +0200, Paolo Carlini wrote:
> Andreas Jaeger wrote:
>
> >>The issue here is ABI stability; if a platform doesn't have large file
> >>support now, but gets it in the future it should be possible to enable
> >>large file support in basic_filebuf without breaking the ABI.
> >>
> >>
> >My point here is type safety, we should use the proper types and not
> >invent some int64_t that works today but breaks in the future
> >(remember when everybody used long instead of off_t - or even int?
> >That makes it quite difficult to convert programs to off64_t).
>
> First blush, I'm definitely on Andreas side, even if I see that P?tur
> has a point...
>
> We should not stabilize a "dirty" (dunno if this is really good english,
> sorry), non type safe ABI for the sake of non-existant systems!
Everybody will get large file access eventually, but some will take
a long time because of backward-compatibility problems. The type
safety argument dictates that we should use a class type for
std::streamoff containing a 64-bit integer type, and publicly defining
(only!) the operations required in 27.4.3.2, and also providing a
named non-inline function to convert between it and a 64-bit integral
value that can be converted to off64_t or what have you. 27.4.3.2
requires that it convert explicitly (but not implicitly!) from, and
implicitly to, std::streamsize without loss for all values that are
representable in std::streamsize. std::streamsize is required to be
a signed built-in integral type, which is not required to be big enough
to represent the size of a file; the standard recommends that it match
ssize_t.
Internally we can use undocumented members to extract and set the
64-bit value for use with lseek64 or what have you.
Nathan Myers
ncm-nospam@cantrip.org