Re: [PATCH] fts.3 is not available in LFS builds

[Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]