Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 05 Jan 2021 10:16:50 -0800
From: Keith Packard <>
To: Florian Weimer <>,
Subject: Re: Future directions for *_r functions

Florian Weimer <> 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.

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?


Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)

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.