fts.3 is not available in LFS builds

As pointed out during a recent discussion on libc-hacker the fts(3) APIs can't be used with large file offsets:

        https://sourceware.org/bugzilla/show_bug.cgi?id=15838

The manpage should mention this. Note: the text probably needs some better formatting at least, but I couldn't come up with proper markup for compiler arguments.

Signed-off-by Christoph Hellwig <[email protected]>

man3/fts.3 +0 -0

index 9374463..2b14c0d 100644

man3/fts.3 +2 -1

+a program using the LFS APIs, e.g. by using
+-D_FILE_OFFSET_BITS=64.
 .\" The following statement is years old, and seems no closer to
 .\" being true -- mtk
 .\" The
--

To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 3 lines

4.4BSD.
+.SH BUGS
+All the APIs described in this manpage are not safe when compiling

Should this perhaps better read "not safe on 32-bit systems"?

Quoted 5 lines · Michael Kerrisk (man-pages)

Quoted 3 lines

4.4BSD.
+.SH BUGS
+All the APIs described in this manpage are not safe when compiling

Should this perhaps better read "not safe on 32-bit systems"?

Well, it works:

a) on a 32-it system if _FILE_OFFSET_BITS is 32 (currently the default)
b) on any 64-bit system

Not sure what the best langauge is to communicate this issue to the user.

I made it

BUGS
All of the APIs described in this man page are not safe when compiling a program using the LFS APIs (e.g., when compiling with -D_FILE_OFFSET_BITS=64). This means these APIs are unus??? able on current 32-bit systems, since those systems are nor??? mally built with -D_FILE_OFFSET_BITS=64.

Quoted 8 lines · Michael Kerrisk (man-pages)

I made it

BUGS
All of the APIs described in this man page are not safe when compiling a program using the LFS APIs (e.g., when compiling with -D_FILE_OFFSET_BITS=64). This means these APIs are unus??? able on current 32-bit systems, since those systems are nor??? mally built with -D_FILE_OFFSET_BITS=64.

Unfortunately that' not quite true - the default is still -D_FILE_OFFSET_BITS=32 for the compiler, so you'd need manual action to change it - which generally is a good idea.

Oh! I thought most distributors built their 32-bit distros with -D_FILE_OFFSET_BITS=64 these days? Am I wrong? (I don't have any 32-bit systems handy to sample from.)

Quoted 3 lines · Michael Kerrisk (man-pages)

Oh! I thought most distributors built their 32-bit distros with -D_FILE_OFFSET_BITS=64 these days? Am I wrong? (I don't have any 32-bit systems handy to sample from.)

I think some build systems try to enforce it, but last time Eric Sandeen checked we still had lots of packages not picking it up.

Quoted 7 lines · Christoph Hellwig

Quoted 3 lines · Michael Kerrisk

Oh! I thought most distributors built their 32-bit distros with -D_FILE_OFFSET_BITS=64 these days? Am I wrong? (I don't have any 32-bit systems handy to sample from.)

I think some build systems try to enforce it, but last time Eric Sandeen checked we still had lots of packages not picking it up.

Okay. I trimmed it back close to your original text:

BUGS
All of the APIs described in this man page are not safe when compiling a program using the LFS APIs on 32-bit systems (e.g., when compiling with -D_FILE_OFFSET_BITS=64).

(Okay?)

maybe we just ignore the issue since fts.h is dead anyways ? just add a section to the fts(3) page recommending people use ftw(3) instead ?

Quoted 2 lines · On Tue 18 Mar 2014 23:12:45 Mike Frysinger wrote:

maybe we just ignore the issue since fts.h is dead anyways ? just add a section to the fts(3) page recommending people use ftw(3) instead ?

i might be completely off on fts vs ftw. there's discussion on glibc lists about maybe fixing fts to not suck. perhaps we just link to the existing bug on the topic ?
https://sourceware.org/bugzilla/show_bug.cgi?id=11460

Quoted 9 lines · On Mon 17 Mar 2014 15:11:18 Michael Kerrisk wrote:

Quoted 7 lines · Christoph Hellwig

Quoted 3 lines · Michael Kerrisk

Oh! I thought most distributors built their 32-bit distros with -D_FILE_OFFSET_BITS=64 these days? Am I wrong? (I don't have any 32-bit systems handy to sample from.)

I think some build systems try to enforce it, but last time Eric Sandeen checked we still had lots of packages not picking it up.

Quoted 8 lines

Okay. I trimmed it back close to your original text:

BUGS
All of the APIs described in this man page are not safe when compiling a program using the LFS APIs on 32-bit systems (e.g., when compiling with -D_FILE_OFFSET_BITS=64).

(Okay?)

not to throw a wrench in there as a pedantic a$$hole, but i find the classic concept of "32-bit and 64-bit systems" to not really fit into modern world (well, it's been this way for much longer, so let's say "mainstream").

would you call all ILP32 ABIs 32-bit ? e.g. mips' n32 or x86's x32. sizeof(long) == 4, but sizeof(off_t) == 8. POSIX describes these as "ILP32 OFF64" while the classic 32-bit systems are "ILP32 OFF".

you can (afaik) use -D_FILE_OFFSET_BITS=64 w/x32 and fts.h and have it work. maybe we just ignore the issue since fts.h is dead anyways ? just add a section to the fts(3) page recommending people use ftw(3) instead ?