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]

Re: static _int_malloc et al


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