This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
RE: [RFC] Large file iostreams
- From: Pétur Runólfsson <peturr02 at ru dot is>
- To: "Paolo Carlini" <pcarlini at unitus dot it>
- Cc: <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 13 Oct 2003 15:20:02 -0000
- Subject: RE: [RFC] Large file iostreams
Paolo Carlini wrote:
> What should happen in 'seekoff'/'seekpos' if the user asks for
> long seek on a platform which doesn't have large file support in
> its glibc? I think Nathan would agree that the best thing to do
> is providing checks that lead to failure. Therefore, the idea
> would be adding an autoconf test for off64_t and, depending on
> it, issuing either a direct low level lseek64 or a check + a
> low level lseek. Do you concur?
Yes, this makes sense.
> About the typedef, I think we have basically two options:
> 1- long long
> 2- int64_t
There is also int_least64_t, but it should be the same as int64_t
on modern hardware.
> I don't remember well the pros and cons of both, but this doesn't
> seem such a difficult to resolve issue.
All 3 have the same problem; they are C99 types. int64_t best
describes the intent, but not all platforms have stdint.h yet.
long long is supplied by the compiler so it is available
everywhere, and it's required to be at least 64 bits, but it
may also be larger (I'm not sure it is on any current platform).
All this can easily be handled with autoconf.
I think it's best to do this change in two steps:
1) Change streamoff to be a class type, but keep using long as the
underlying type.
2) Switch to lseek64 and change the underlying type.
There is one more issue I would like input on before preparing a
patch. Is config/os/gnu-linux/fpos.h needed? It doesn't seem to
provide much over the generic version, it doesn't support stateT
other than mbstate_t, and having two versions of the code makes
testing harder.
Regards,
Petur