This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use offsetof instead of magic number in scandir()

On 03/28/2013 02:54 PM, Corinna Vinschen wrote:
On Mar 28 14:36, Sebastian Huber wrote:
On 03/28/2013 01:42 PM, Corinna Vinschen wrote:
On Mar 28 12:44, Sebastian Huber wrote:
On 03/28/2013 12:17 PM, Corinna Vinschen wrote:
Shouldn't we better use the upstream version as used in FreeBSD and

   #define DIRSIZ(dp)                                                      \
           ((sizeof(struct dirent) - sizeof(dp)->d_name) +                 \
	      (((dp)->d_namlen + 1 + 3) &~ 3))

I have problems to understand this expression.  What is
"sizeof(dp)->d_name"? I think this looks like a hand-crafted
offsetof variant.
sizeof(dp)->d_name is sizeof((dp)->d_name), but without the lexically
unnecessary parens.  I was just thinking that using the upstream
version has the advnatage to use easier comparable code, given that
our scandir.c is the BSD version anyway.

Ok, this makes sense.  Should I use the FreeBSD version of DIRSIZ()
including its formatting?

It seems that the scandir() implementations diverged a bit.  In
Newlib we have this bugfix:

commit c7ec1406e5abb6f1ec6363e1d13061934c1746e9
Author: Jeff Johnston <>
Date:   Mon Nov 24 20:42:33 2008 +0000

     2008-11-24  Joel Sherrill <>

             * libc/posix/scandir.c: Fix memory leaks.

Maybe we should report this to the BSDs.

OpenBSD as well as FreeBSD have both fixed this issue, albeit slightly
different from our version.

Yes, they fixed this bug ten years earlier:

FreeBSD also changed the comparison function to ensure POSIX 2008 conformance:

This is a difference to Newlib.

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  :
PGP     : Public key available on request.

Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]