[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZorLtj-XpZkDB9XD3Mp7w1i7bToFOkKpo=pofaYGEpL7bg@mail.gmail.com>
Date: Tue, 5 Jan 2021 10:44:08 -0800
From: enh <enh@...gle.com>
To: libc-coord@...ts.openwall.com
Cc: Florian Weimer <fweimer@...hat.com>
Subject: Re: Future directions for *_r functions
On Tue, Jan 5, 2021 at 10:17 AM Keith Packard <keithp@...thp.com> wrote:
> Florian Weimer <fweimer@...hat.com> writes:
>
> > Personally, I'm leaning towards the first option (thread-safe non-_r
> > variants plus dup*ent and free*ent helpers). That's largely based on my
> > exposure to the current glibc implementation and the interfaces it
> > provides to programmers.
>
> Agreed. Making the 'normal' libc API thread safe has huge benefits to
> existing applications which will not need to be rewritten to take
> advantage of these fixes. I've implemented a mixture of atomic
> operations, locking and thread-local values for some of the _r functions
> in picolibc, but that doesn't include the huge range of network-facing
> functions found in larger libraries.
>
we did this years ago in bionic for Android (in part because we found that
the majority of callers were broken and assuming this anyway). overall it's
been a success, and it's one of the more interesting things that we did
that i'd definitely still do if i had my time again.
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.)
even so, almost nothing hit this in practice, and the number of bugs we
*fixed* by making these functions a closer match for folks' assumptions far
outweighed that.
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 only problem with thread-local values is that when exposed in the
> API (such as withh lgamma_r's signgam), they are not ABI compatible. I
> *think* symbol versioning could help here?
>
okay, when i said "we did this years ago", lgamma(3) is one we didn't
actually do :-)
i've honestly never seen lgamma(3) used --- afaict the folks writing math
code all know to use lgamma_r(3). a quick code search suggests that when it
is used, it's often used in ways that could fall victim to the basename(3)
gotcha above. here i'd be tempted to just `__attribute__((__deprecated__))`
lgamma(3) and suggest lgamma_r(3) instead. (but, for lack of folks writing
incorrect math code, i haven't actually done anything to date. i have no
anecdata for whether the math folks learn this the hard way through bug
reports or it's just known folklore that you never use lgamma(3)...)
> --
> -keith
>
Content of type "text/html" skipped
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.
