This is the mail archive of the libc-alpha@sourceware.org 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 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?

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

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


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