[PATCH] Fix readdir_r with long file names

[KOSAKI Motohiro]

(6/7/13 10:41 AM), Rich Felker wrote:
> On Fri, Jun 07, 2013 at 09:55:47AM +0200, Florian Weimer wrote:
>> On 06/07/2013 03:30 AM, Rich Felker wrote:
>>> On Thu, Jun 06, 2013 at 03:53:16PM -0400, KOSAKI Motohiro wrote:
>>>> I mean, portable applications should use readdir_r correctly and Linux specific
>>>> one should use readdir instead.
>>>>
>>>> Side note: the above man page is not a theoretical issue. At least, Solaris
>>>> requires it.
>>>>
>>>> Am I missing something?
>>>
>>> Yes, the fact that the Austin Group is planning to require readdir to
>>> be thread-safe and to mark readdir_r obsolescent.
>>
>> This is good news.
>
> Very good news. I've wanted this change ever since I first learned
> about readdir_r, and I'm very glad this NAME_MAX issue has provided
> the push to get it done.

That's pretty good news. So then, I'm ok to make a limitation into readdir_r()
and discourage to use it.

So....

> +@code{readdir} is not thread safe.  In @theglibc{} implementation,
> +multiple threads using @code{readdir} on the same @var{dirstream} may
> +overwrite the return value.

This is true. but not good wording choice. Many developers may parse this
mean you encourage to use readdir_r().

How's this?

+@code{readdir} is thread safe while @var{dirstream} is not shared from
+multiple threads. In @theglibc{} implementation, multiple threads using
+@code{readdir} on the same @var{dirstream} mayoverwrite the return value.


> +The use of @code{readdir_r} is a
> +thread-safe alternative, but may suffer from poor portability.  If
> +portability is required it is recommended that you use @code{readdir},
> +with external locking if multiple threads access the same
> +@var{dirstream}.

I suggest to remove this because I don't think we need to suggest semi
obsolete functions.



>
>>> So effort put into
>>> making readdir_r more usable, or worse yet, adding a readdir4, is a
>>> waste of effort. Just make sure readdir_r is _safe_ against buffer
>>> overflows from buggy FUSE modules, and advise application developers
>>> to use readdir, not readdir_r.
>>
>> Does this mean that you agree with the basic approach of the patch?
>
> Yes. I just disagree with recommending that portable applications use
> readdir_r (as discussed on the Austin Group tracker/list, it has major
> problems related to NAME_MAX not being mandatory) and with the idea
> (by someone else, not you) to add a readdir4 rather than just
> deprecating caller-provided buffers for reading directories. Those
> were the only things I was commenting on.