Re: Adding reentrancy information to safety notes?

["Carlos O'Donell" <carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 12/31/2014 04:31 AM, Alexandre Oliva wrote:
> On Dec 31, 2014, "Carlos O'Donell" <carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html