This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
[RFC] Another look at LFS vs filebuf::showmanyc
- From: Paolo Carlini <pcarlini at suse dot de>
- To: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Cc: Nathan Myers <ncm at cantrip dot org>
- Date: Mon, 20 Sep 2004 17:49:13 +0200
- Subject: [RFC] Another look at LFS vs filebuf::showmanyc
Hi,
upon Benjamin's invitation, I'm having another look at the open issue in
libstdc++/12882, that is __basic_file<>::showmanyc not using fstat64
(neither lseek64) and therefore not useful for LFS: filebuf::showmanyc
ends up returning zero for large files: conforming but very low QoI.
The last time I tried to fix this, glibc was not making visible
automagically,
thanks to -D_GNU_SOURCE, fstat64 - this happens, instead, for fopen64 &
co -
and I resigned...
Now, the *very good* news (thanks Benjamin for asking me to persist ;) is
that most probably this was only a glibc bug, *fixed* in the meanwhile: it
looks like I can compile and link the below with the C++ compiler, without
any special command line argument:
#include <sys/stat.h>
int main()
{
struct stat64 buf;
fstat64(1, &buf);
}
But... There is also the *bad* news (and that's why I'm posting an RFC
instead
of a patch ;)
According to the C++ standard, filebuf::showmanyc returns a *streamsize*,
which is a ptrdiff_t, that is **always** 32 bits on 32-bit platforms,
even if LFS-enabled... Therefore, on real large files, a fixed showmanyc
would typically overflow the type of its return value :( :(
What I'm missing? Can we do something about that? Or we should just give up
and close (the remaining bit of) 12882 as WONTFIX?
Thanks in advance for any feedback,
Paolo.