This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> Why wouldn you want to tie yourself to a specific implementation of > malloc? The _int_* functions have no interface which is in any way > universal and should be preserved if the implementation changes. The purpose of those interfaces is to use private arenas segregated from the common malloc heap. That's what I expect to want (when I get around to it--the Hurd port needs this, and already has it now by virtue of having a separate, very crappy, allocator for some internal uses). The interface is trivially based on the canonical malloc et al interfaces, so I am not worried about whatever slight adaptations might be needed if the implementation changes. > I've changed the code to use static since the generated code uses tail > calls. This can perhaps be achieved with hidden as well but for the > above reasons I need more convincing. I am presuming that attribute_hidden has all the code-generation benefits of static, since that's what it's for. That's why I suggest not changing it now, even though the _int_* have yet to be used, since I don't think there's a downside.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |