This is the mail archive of the
mailing list for the libstdc++ project.
Re: [Patch] Fix libstdc++/11378 (take2) + xsputn optmizations
- From: Andreas Jaeger <aj at suse dot de>
- To: Pétur Runólfsson <peturr02 at ru dot is>
- Cc: "Paolo Carlini" <pcarlini at unitus dot it>, <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 08 Jul 2003 21:49:59 +0200
- Subject: Re: [Patch] Fix libstdc++/11378 (take2) + xsputn optmizations
- References: <07D05A69A3D0C14FAEA60C3ACE8E5564028F558E@nike.hir.is>
Pétur Runólfsson <email@example.com> writes:
> Andreas Jaeger wrote:
>> You can use lseek64 and off64_t, there should be no problem (if lseek
>> is part of the C library).
> Is off64_t available on all platforms supported by gcc? Otherwise it's
> probably better to use int64_t everywhere (also on platforms that
> don't have large file support now).
off64_t is not available everywhere - and int64_t might not be
available everywhere also.
> 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).
Andreas Jaeger, firstname.lastname@example.org, http://www.suse.de/~aj
SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126