[Rpm-maint] PATCH 3/2013 Improve BSD support in fts.c and review the 'struct stat64' usage

[Panu Matilainen]

On 08/17/2013 07:15 PM, Kamil Rytarowski wrote:
> Hello,
>
> I'm attaching a patch improving BSD (Free, Net and Open) support with the following change-log:
>
> Improve BSD support.
> Tested with NetBSD 6.1, OpenBSD patch against sources available in public (5.3).
> FreeBSD patch based on FreeBSD ports.
>
> 'struct stat64' isn't portable and it usage wasn't done properly, as it was mixed 'struct stat64' with 'struc stat' on stat64-compatible systems and broken on stat-only ones (most notably on NetBSD and OpenBSD).
>
> Please review and apply.

NAK as-is at least, this introduces several warnings on Linux (Fedora 19):

fts.c: In function 'fts_stat':
fts.c:882:43: warning: pointer type mismatch in conditional expression 
[enabled by default]
   sbp = ISSET(FTS_NOSTAT) ? &sb : p->fts_statp;
                                            ^
fts.c:901:3: warning: passing argument 2 of 'sp->fts_stat' from 
incompatible pointer type [enabled by default]
    if ((*sp->fts_stat) (p->fts_accpath, sbp)) {
    ^
fts.c:901:3: note: expected 'struct stat *' but argument is of type 
'struct stat64 *'
fts.c:903:4: warning: passing argument 2 of 'sp->fts_lstat' from 
incompatible pointer type [enabled by default]
     if (!(*sp->fts_lstat) (p->fts_accpath, sbp)) {
     ^
fts.c:903:4: note: expected 'struct stat *' but argument is of type 
'struct stat64 *'
fts.c:910:2: warning: passing argument 2 of 'sp->fts_lstat' from 
incompatible pointer type [enabled by default]
   } else if ((*sp->fts_lstat) (p->fts_accpath, sbp)) {
   ^
fts.c:910:2: note: expected 'struct stat *' but argument is of type 
'struct stat64 *'
fts.c: In function 'fts_alloc':
fts.c:1013:16: warning: assignment from incompatible pointer type 
[enabled by default]
    p->fts_statp = (struct stat64*)ALIGN(p->fts_name + namelen + 2);
                 ^

> fts.* are waiting for next patches.
> After merging all BSD related ones into the whole codebase (to make it buildable), everything will be retested with the three most known BSD systems.

What I'd actually prefer is getting rid of the bundled fts 
implementation entirely. It's a slightly modified, no doubt bit-rotten 
copy of a 2002-era glibc implementation which has then been since then 
revised for portability several times. The original reason for bundling 
fts was apparently improved portability and getting rid of a home-grown 
ftw() version which didn't follow symlinks.

Dunno about 2002 but these days nftw() is defined in POSIX (fts is not) 
and seems like it should be up to the task. I haven't had a serious look 
at it though so its possible rpm depends on some fts specific behavior.

	- Panu -