This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]