Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Jan 2016 17:44:49 -0500
From: Rich Felker <>
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
> ---
>  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_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


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.