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: Tue, 8 Mar 2016 13:20:07 +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> <56D620AA dot 40108 at redhat dot com> <56D624FE dot 1090702 at cs dot ucla dot edu> <56D6294A dot 5040703 at redhat dot com> <56D72683 dot 6010302 at cs dot ucla dot edu>
On 03/02/2016 06:44 PM, Paul Eggert wrote:
> +/* Declare a structure member named ID, with type "array of TYPE", and
> + with actual size unspecified but with nominal size SIZE for the
> + benefit of traditional applications. If the application is
> + compiled with _FLEXARRAY_SOURCE and if the compiler is C99 or
> + better, model this as a flexible array. Otherwise, model it as a
> + fixed-size array of size SIZE (followed by a flexible array
> + afterwards, if C99, for the benefit of source-code analyzers that
> + can use this as a cue that the array is really varying-size). The
> + fixed-size array is for compatibility with programs that unwisely
> + take the size of structures that contain flexible arrays, and which
> + rely on traditional glibc which uses fixed-size arrays. */
> +#ifndef __flexarray
> +# ifdef __USE_FLEXARRAY
> +# define __flexarray(id, type, size) type id[]
> +# else
> +# define __flexarray(id, type, size) type id[size]; type __flexarray __flexarr
> +# endif
> +#endif
Sorry, I'm not convinced this is good compiler hint. I suspect it moves
things in the opposite direction. Some compilers likely have hacks to
support arrays of length 1 as flexible arrays if the array is at the end
of a struct, and after your change, the member is no longer at the end,
potentially disabling the flexible array kludge.
I think we should interact better with compilers in this area, but this
needs fairly explicit mark-up, showing what we need, and not something
that requires the compiler to guess.
Thanks,
Florian