This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix readdir_r with long file names
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, "Carlos O'Donell" <carlos at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, linux-man <linux-man at vger dot kernel dot org>
- Date: Wed, 2 Mar 2016 00:07:22 +0100
- Subject: Re: [PATCH] Fix readdir_r with long file names
- Authentication-results: sourceware.org; auth=none
- References: <51B0B39F dot 4060202 at redhat dot com> <51B0BD36 dot 3030202 at redhat dot com> <CAHGf_=r9Rz63pho+84ORk0a_oDyJSj-MCnZ56uPrT3L6sVEfeQ at mail dot gmail dot com> <20130607013024 dot GO29800 at brightrain dot aerifal dot cx> <51B19203 dot 3070307 at redhat dot com> <20130607144143 dot GQ29800 at brightrain dot aerifal dot cx> <51B57E35 dot 4080403 at redhat dot com> <51B65EA7 dot 2020402 at redhat dot com> <20130611011324 dot GT29800 at brightrain dot aerifal dot cx> <51B8702D dot 2060505 at redhat dot com> <20130813040038 dot GE21795 at spoyarek dot pnq dot redhat dot com> <520C88A6 dot 9070501 at redhat dot com> <56D54DAD dot 1040306 at gmail dot com> <56D5CA79 dot 9030204 at redhat dot com> <56D5F832 dot 3070209 at gmail dot com> <56D5FB3D dot 5000306 at redhat dot com> <56D607BB dot 6080701 at cs dot ucla dot edu> <56D614AA dot 7020500 at redhat dot com> <56D61A86 dot 3050108 at cs dot ucla dot edu>
On 03/01/2016 11:41 PM, Paul Eggert wrote:
> On 03/01/2016 02:16 PM, Florian Weimer wrote:
>>> Why not use a flexible array member for this?
>> For which part, and how exactly?
>
> Something like the attached patch, say. (Totally untested.)
>
>> You can't put a flexible array member into a transparent union.
>
> That's OK. Any such usage of struct dirent would be unportable anyway.
>
>> If you mean to add some zero-width padding member at the end of the
>> struct, after the d_name member, then I'm worried that makes overrunning
>> the d_name array member even more undefined than it already is.
>
> No, no padding member, just use C99 the way it was designed. This
> should improve overrun detection in programs like valgrind. With glibc's
> current definition these programs can be fooled into thinking that
> struct dirent accesses are invalid (outside of array bounds) when they
> are actually OK, so people shut off array-bounds checking. If we used
> flexible array members, valgrind etc. should know that the array's upper
> bound is unknown and should not issue so many false alarms, so people
> can leave bounds checking on.
I don't think valgrind can see the difference, but you are correct in
principle (this is essentially the âundefinedâ part I was worried about).
Unfortunately, GCC does not produce a warning for taking the size of a
struct with a flexible member, or for using it in a non-pointer
declarator, so it does only half of what we want. And at the cost of
changing sizeof (struct dirent), which can't be a good thing.
> If flexible arrays are no-go for some reason, I suppose we could use
> 'char 'd_name[SIZE_MAX - 1000];' instead. That should get peoples'
> attention. :-)
GCC refuses to compile the type definition, not just declarations.
Refusing declarations with an error would break quite a lot of existing
configure tests.
struct dirent d; int z; z - d.d_ino;
is a common idiom to check for struct members.
Florian