This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Adding reentrancy information to safety notes?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, Michael Kerrisk <mtk dot manpages at gmail dot com>, Peng Haitao <penght at cn dot fujitsu dot com>, "linux-man at vger dot kernel dot org" <linux-man at vger dot kernel dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 31 Dec 2014 10:26:13 -0500
- Subject: Re: Adding reentrancy information to safety notes?
- Authentication-results: sourceware.org; auth=none
- References: <54A2C8A6 dot 9050100 at redhat dot com> <ork318eoj4 dot fsf at livre dot home> <20141230230529 dot GT4574 at brightrain dot aerifal dot cx> <orfvbwegqg dot fsf at livre dot home> <54A377B8 dot 60802 at redhat dot com> <ortx0cdv3c dot fsf at livre dot home>
On 12/31/2014 04:31 AM, Alexandre Oliva wrote:
> On Dec 31, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
>
>> The reason I want to use this definition is to more formally describe
>> those functions which are safe to call from a user provided malloc.
>> A user provided malloc can be called from almost anywhere in glibc, it
>> interrupts core glibc code, it only synchronously interrupts core
>> glibc code (when malloc is called), and limiting a user provided malloc
>> to AS-safe functions would be punative (though that is what we'll be
>> doing in the initial documentation pass).
>
> Hmm... Given that making malloc AS-Safe is reuqired POSIX compliance,
> what would we gain by enabling malloc implementations to call functions
> beyond other AS-Safe functions? I mean, a malloc implementation cannot
> be AS-Safe if it calls AS-Unsafe functions, nor can it be MT-Safe if it
> calls MT-Unsafe functions, even if they are Reentrant under the
> definition you provided, so... Wouldn't enabling malloc to call them
> making sure we won't ever be able to make malloc AS-Safe, and thus
> POSIX-compliant?
I did not know malloc was required to be AS-safe for POSIX compliance.
Could you please quote the relevant part of the issue 7 standard?
See: http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
2.4.3 Signal Actions.
The list of functions does not list malloc.
>> Hopefully that clarifies the definition of reentrancy.
>
> Yes, thanks for all the effort into clarifying what you meant, even
> though just the definition would have been enough.
My pleasure. A list of examples helps not just you but future readers.
Cheers,
Carlos.