Re: [PATCH] Fix readdir_r with long file names

[Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 03/01/2016 10:20 PM, Paul Eggert wrote:
> On 03/01/2016 12:27 PM, Florian Weimer wrote:
>> We
>> should implement compiler support for this wart: inhibit optimizations
>> (I think there are already special cases for length-0 and length-1
>> arrays at the end, so it's not totally without precedent), and warn
>> about sizeof (struct dirent) and using it as a (non-pointer) declarator.
> 
> Why not use a flexible array member for this?

For which part, and how exactly?

You can't put a flexible array member into a transparent union.

> Sure, that assumes C99,
> but flexible array members are pretty much universally supported now
> (and we can fall back on the current layout for pre-C99 compilers). This
> would work better with modern compilers that treat small arrays with
> more respect than traditional C compilers did. And as I understand
> things, it would conform to POSIX (and if I'm wrong, POSIX should get
> fixed....).

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. :)

> For what it's worth, portable code cannot copy struct dirent values
> anyway, as this loses file names in operating systems like Solaris where
> d_name has size 1.

Interesting.  I feel slightly better now about having this overrunning
d_name member.

Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html