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

From: Ulrich Drepper <drepper at redhat dot com>
To: Roland McGrath <roland at redhat dot com>
Cc: GNU libc hackers <libc-hacker at sources dot redhat dot com>
Date: Tue, 07 Jan 2003 00:13:20 -0800
Subject: Re: static _int_malloc et al
Organization: Red Hat, Inc.
References: <200301070750.h077oNi07630@magilla.sf.frob.com>

Roland McGrath wrote:

> Is there any special reason _int_malloc et al should be static rather than
> just hidden?  I anticipate at some point using these routines from another
> part of libc, in the Hurd port at least.

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.

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.

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

Follow-Ups:
- Re: static _int_malloc et al
  - From: Roland McGrath
- Re: static _int_malloc et al
  - From: Wolfram Gloger

References:
- static _int_malloc et al
  - From: Roland McGrath

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