Re: [PATCH] Trust AC_SYS_LARGEFILE to provide large file support

[Mark Wielaard <mjw at redhat dot com>]

On Fri, Oct 09, 2015 at 09:40:49AM -0700, Josh Stone wrote:
> On 10/09/2015 04:17 AM, Mark Wielaard wrote:
> > What is the story behind fts.h? Is its usage not off_t 64bit clean?
> 
> See https://sourceware.org/bugzilla/show_bug.cgi?id=11460
> 
> Of course it does support 64-bit off_t, as it must for native 64-bit
> platforms.  I guess the problem is just that it doesn't have the
> duplicated interfaces for 32-bit with/without _FILE_OFFSET_BITS.
> 
> Note that struct _ftsent contains a struct stat.  So it would need
> versions with either stat or stat64, and all of the functions updated to
> swing both ways too.

That is a pity, since we explicitly use FTS_NOSTAT so the stat call
and the struct stat value are completely unused.

> There is the similar ftw.h which has full LFS, but the FTW_SKIP_SUBTREE
> action is a GNU extension.  We now use FTS_SKIP to prune the "source"
> directory from kernel module walks.  We wouldn't be able to do this with
> ftw on FreeBSD, for example, but it's for Linux modules anyway so maybe
> we don't care.
>
> Want to convert to ftw and accept the lack of skipping as a fallback?
> (There may be other fts/ftw differences that I haven't noticed yet.)

The major other difference seems to be that with (n)ftw you always
stat every file explicitly. Which seems precisely what we want to
avoid in this case because we are only interested in the names.

Since it is indeed linux kernel module specific and we now have that
test to make sure we don't accidentially use non-lfs symbols I think
for now we should just leave it. It might be nice to make the glibc
implementation LFS compliant. Then we could just have a configure test
to see whether or not fts.h can be included with/without _FILE_OFFSET_BITS
set. But that seems something for that far future.

Thanks,

Mark