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

Sebastian Huber sebastian.huber@embedded-brains.de
Thu Mar 28 13:43:00 GMT 2013


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.



More information about the Newlib mailing list