This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding reentrancy information to safety notes?

On 12/31/2014 04:31 AM, Alexandre Oliva wrote:
> On Dec 31, 2014, "Carlos O'Donell" <> 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?

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]