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: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: kosaki dot motohiro at gmail dot com, Florian Weimer <fweimer at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 07 Jun 2013 17:10:05 -0400
- Subject: Re: [PATCH] Fix readdir_r with long file names
- References: <20130516125029 dot GE11420 at spoyarek dot pnq dot redhat dot com> <5194D697 dot 8040106 at redhat dot com> <20130516130952 dot GA16952 at spoyarek dot pnq dot redhat dot com> <519B58EC dot 6060108 at redhat dot com> <51B0A2F9 dot 5060004 at redhat dot com> <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>
(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.