On Dec 31, 2014, "Carlos O'Donell" <carlos@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
