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

[Paolo Carlini <pcarlini at unitus dot it>]

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.