[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Jan 2016 17:44:49 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] add _DIRENT_HAVE_D_* constants to dirent.h
On Wed, Jan 13, 2016 at 07:09:19PM +0100, Felix Janda wrote:
> they can be used for checking existence of non-standard fields of
> struct dirent, are used by various programs to avoid configure
> checks and are at least present on glibc, uclibc, dietlibc and
> newlib.
> ---
> The motivation for this patch is
>
> http://oss.sgi.com/archives/xfs/2016-01/msg00388.html
> ---
> include/dirent.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/dirent.h b/include/dirent.h
> index 5aa8510..b2ffe8a 100644
> --- a/include/dirent.h
> +++ b/include/dirent.h
> @@ -57,6 +57,9 @@ int getdents(int, struct dirent *, size_t);
> #endif
>
> #ifdef _GNU_SOURCE
> +#define _DIRENT_HAVE_D_OFF
> +#define _DIRENT_HAVE_D_RECLEN
> +#define _DIRENT_HAVE_D_TYPE
> int versionsort(const struct dirent **, const struct dirent **);
> #endif
I like the concept of defining macros to publish the availability of
extensions like this, but I don't think they should be dependent on
_GNU_SOURCE. At the very least they should also be available under
_DEFAULT_SOURCE (_BSD_SOURCE), but since they're in the reserved
namespace (underscore followed by capital) I'd prefer to have them
exposed unconditionally.
I'm also skeptical of whether d_off and d_reclen should be promoted as
public APIs. They don't seem to be useful (unlike d_type which is
highly useful) and may lock down some assumptions about
implementation.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
