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.