This is the mail archive of the newlib@sourceware.org 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:36 PM, 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
> >OpenBSD?
> >
> >   #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?

http://svnweb.freebsd.org/base/head/lib/libc/gen/scandir.c?revision=202693&view=markup


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

commit c7ec1406e5abb6f1ec6363e1d13061934c1746e9
Author: Jeff Johnston <jjohnstn@redhat.com>
Date:   Mon Nov 24 20:42:33 2008 +0000

     2008-11-24  Joel Sherrill <joel.sherrill@oarcorp.com>

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

Maybe we should report this to the BSDs.

Sorry, FreeBSD fixed also this bug, but slightly different.

--
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  : sebastian.huber@embedded-brains.de
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]