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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
