Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jan 2001 17:40:28 -0500
From:      "Brian F. Feldman" <green@FreeBSD.org>
To:        Daniel Eischen <eischen@vigrid.com>
Cc:        Warner Losh <imp@harmony.village.org>, "Jacques A. Vidrine" <n@nectar.com>, arch@FreeBSD.org
Subject:   Re: Request For Review: libc/libc_r changes to allow -lc_r 
Message-ID:  <200101212240.f0LMeSc20272@green.dyndns.org>
In-Reply-To: Message from Daniel Eischen <eischen@vigrid.com>  of "Sun, 21 Jan 2001 16:44:38 EST." <Pine.SUN.3.91.1010121163706.15942A-100000@pcnet1.pcnet.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen <eischen@vigrid.com> wrote:
> On Sun, 21 Jan 2001, Warner Losh wrote:
> > In message <Pine.SUN.3.91.1010121162703.14751A-100000@pcnet1.pcnet.com> Daniel Eischen writes:
> > : Oops, sorry, I missed the second question.  You need _foo to be
> > : used within libc, so that when libc_r/libpthread is linked in,
> > : it can provide a replacement function for it.  We also need to
> > : determine if the function is a cancellation point or not, so
> > : if you just had foo and __sys_foo, libc_r/libpthread would have
> > : no way of knowing if foo was called from within libc or from
> > : the user application.  The former is not a cancellation point,
> > : while the latter is (if foo is read for example).
> > 
> > I understand that.  I guess my question is why name it _foo instead of
> > __foo?  I see the need for the tripartiteness, just not the need to
> > call it _foo.
> 
> I guess it doesn't matter to me wether it's _foo or __foo, but
> we do have to use it within libc.  We've already done the work
> to use _foo in libc, so it's extra work to go back and use __foo.
> I guess this gets back to the ANSI namespace issue.  Our using
> _foo in libc doesn't affect an applications namespace because
> it's a weak definition; anything the user provides will override
> it.  But, that means that our internal use of _foo would then
> call the user applications _foo.

Yes, this is much too risky... if the two namespaces clearly stay away from 
eachother, then there's no worrying about this (unless you're a library 
writer who needs global __xxx symbols for some reason).

> If it's OK for folks to see and use __foo in libc as opposed
> to _foo, I can make that change.

It's much too dangerous, I believe, to let libc escape out into the 
application's namespace much.

-- 
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green@FreeBSD.org                    `------------------------------'




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101212240.f0LMeSc20272>