bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] fts.m4: correct the test for statfs.f_type


From: Jim Meyering
Subject: Re: [PATCH] fts.m4: correct the test for statfs.f_type
Date: Wed, 01 Oct 2008 17:18:44 +0200

Bruno Haible <address@hidden> wrote:
>> I noticed that the configure-time test for the f_type member
>> of struct statfs was failing on some systems.
>>
>> It didn't include <sys/statfs.h>.
>> I've pushed the obvious fix:
>
> This introduces a regression on HP-UX.
>
> The use of HAVE_STRUCT_STATFS_F_TYPE is predicated by
> HAVE_SYS_VFS_H && HAVE_FSTATFS. Without this predicate, the test would
> fail to detect that 'struct statfs' has an f_type field on MacOS X, *BSD,
> HP-UX, and OSF/1. With this predicate, the test fails to detect it on
> HP-UX.
>
> Here's the matrix:
>
>              fstatfs()    <sys/statfs.h>   <sys/vfs.h>    f_type
>
> glibc          *               *               *            *
> MacOS X        *                                            *
> FreeBSD        *                                            *
> OpenBSD        *                                            *
> NetBSD         *                                            *
> AIX                            *               *            *
> HP-UX          *                               *            *
> IRIX           *               *               *
> Solaris        *               *               *
> OSF/1          *                                            *
> Cygwin         *               *               *            *
>
> 'struct statfs' is defined
>   - in <sys/statfs.h> on glibc, AIX, IRIX, Solaris.
>   - in <sys/mount.h> on MacOS X, FreeBSD, OpenBSD, NetBSD, OSF/1.
>   - in <sys/vfs.h> on Cygwin, HP-UX.

Thanks, Bruno.

Is that a real regression?
Sure, it may fail to detect the member, but detecting
the f_type member is useful only if the system in question
may have a local file system on which the sorting is known
to be a wasted effort, and is thus best avoided.

I measured it for tmpfs, and presumed for nfs.
My main motivation for adding that test was not to improve
performance (it's minimal) but rather to eliminate the potential
for memory allocation failure.

If someone is interested enough to time things on HP-UX
and finds that there's a file system type (probably memory backed)
that it'd be good to exempt, then it might be worthwhile to
pursue this.  Even then, considering the size of HP-UX market
share, I'd argue it's not worth the effort to make such a small
optimization.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]