On Mon 17 Mar 2014 15:11:18 Michael Kerrisk wrote: > On Mon, Mar 17, 2014 at 3:06 PM, Christoph Hellwig wrote: > > On Mon, Mar 17, 2014 at 03:02:53PM +0100, Michael Kerrisk wrote: > >> 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?) 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 ? -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
