[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87pn2fviy1.fsf@oldenburg2.str.redhat.com>
Date: Fri, 08 Jan 2021 11:09:26 +0100
From: Florian Weimer <fweimer@...hat.com>
To: enh <enh@...gle.com>
Cc: libc-coord@...ts.openwall.com
Subject: Re: Future directions for *_r functions
> iirc basename(3) was the place where we caused problems in
> practice. basically with the GNU basename(3) [but not the POSIX one!]
> it's a valid assumption that you can call basename(3) on two different
> strings and compare the results, say, whereas on Android the second
> call will have overwritten the first result, and both calls will have
> returned the same pointer to TLS. (see
> http://lists.landley.net/pipermail/toybox-landley.net/2015-June/007439.html
> for example.)
Ah:
| bionic's "POSIX" basename had the wrong CV-qualifiers since at least
| cupcake (there was no NDK before that, so it didn't matter that it was
| wrong until then), so even today it never modifies its arguments and
| uses a thread-local buffer for backwards compatibility (with Android;
| obviously this is an incompatibility with glibc).
I think neither the POSIX nor GNU definition *require* a static buffer,
although POSIX permits it, and even deals with the TLS case (“The
returned pointer might also be invalidated if the calling thread is
terminated.”, first time I see language like that in POSIX.)
> readdir_r(3) has long been my favorite example of the "why _r is
> terrible" side of the argument. almost every use of readdir_r(3) i've
> ever seen has been wrong, not least in Android, internal Google code,
> and all the third-party open source code they pull in. (i assume
> everyone on this list is familiar with the horror that is
> readdir_r(3), but if not, see
> http://elliotth.blogspot.com/2012/10/how-not-to-use-readdirr3.html for
> more.)
The readdir_r deprecation has been rather painful, with lots of
developers working around -Werror failures rather than switching to
readdir.
In glibc, we patched readdir_r to check agains NAME_MAX, and return
ENAMETOOLONG at the end of the directory stream if it encounters an
overly long name.
I think POSIX has agreed to remove the interface in a future version.
I believe this is all the result of an old implementation of fdopendir
as
DIR *fdopendir(fd)
{
return fd;
}
For that to work, readdir has to use a static buffer.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
