This is the mail archive of the
mailing list for the glibc project.
Re: Should glibc be fully reentrant? -- No. (Roland was right).
- From: Florian Weimer <fweimer at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Thu, 11 Dec 2014 14:50:18 +0100
- Subject: Re: Should glibc be fully reentrant? -- No. (Roland was right).
- Authentication-results: sourceware.org; auth=none
- References: <5488F9C6 dot 9080605 at redhat dot com> <54898FE0 dot 8060701 at redhat dot com> <20141211133353 dot GB10717 at domone>
On 12/11/2014 02:33 PM, OndÅej BÃlka wrote:
On Thu, Dec 11, 2014 at 01:36:48PM +0100, Florian Weimer wrote:
On 12/11/2014 02:56 AM, Carlos O'Donell wrote:
After serious review it seems like we will need to start by
saying that an interposed malloc must operate as-if it were
in async-signal context and use only those functions which
are marked as async-signal-safe.
Practically speaking, this seems rather restrictive. Most mallocs
need locking, and implementations may want to use pthread mutexes.
Those are not async-signal-safe, and I doubt they can be made
No, making them reentrant is relatively simple as I wrote before, just
wrap calls in something
static __thread int recursed
I meant the locking functions.
Anyway, the above needs a volatile specifier somewhere, and even then,
it might still be outside of what can be expressed in C.
Florian Weimer / Red Hat Product Security