libstdc++/8610: std::streamoff type is 32-bit in GCC 3.2 whereas it was 64-bit in GCC 2.96

Paolo Carlini pcarlini@unitus.it
Sat Feb 8 21:50:00 GMT 2003


Andreas Jaeger wrote:

>Paolo, I need some help here since I don't know the internals of
>libstc++.
>
Hi Andreas and thanks for your _very_ quick reply!
My impression, in general, is that enabling LFS for libstdc++ is a
new project! I would appreciate having some general guidelines from
you and trying to work on it in the next few months...
So:

>/opt/gcc/3.4-devel/include/c++/3.4/i686-pc-linux-gnu/bits/c++io.h
>(where does this file come from?) indeed defines:
>namespace std 
>{
>// for fpos.h
>  typedef long          streamoff;
>  typedef ptrdiff_t     streamsize; // Signed integral type
>
It comes from libstdc++-v3/config/io/c_io_stdio.h. It's wrong, right?
What should be, instead, off64_t?

Is this the correct type, which becomes a real 64 bit type as soon
as _FILE_OFFSET_BITS=64 is defined?

Also, why _two_ different defines are needed, both _FILE_OFFSET_BITS=64
and _LARGEFILE_SOURCE ?? Could you please explain a bit?

>And libstdc++/config/io/c_io_libio.h has:
>
Disregard this file: it was only used by the old libio.

>But the problem is even more subitle.  config/io/basic_file_stdio.cc
>uses fseek/ftell which use a long int and therefore - under 32-bit -
>allow only 2 GB. You should use fseeko/ftello or fsetpos/fgetpos.
>
I see... Isn't possible to have a single name for both 32 and 64 bit
which transparently adapts according to the value of the defines??
Is it fseeko/ftello?
I read in the glibc docs that open64 for instance can be avoided and
only open used transaparently...
In your opinion, which amount of transparency can be achieved?
I mean, it will ever be possible to have one single libstdc++, which,
without configure magic, becomes LFS only by setting 
_FILE_OFFSET_BITS=64 and _LARGEFILE_SOURCE when it's compiled?

Thanks for your past and future help,
Paolo.



More information about the Gcc-bugs mailing list