Date: Sun, 21 Jan 2001 17:54:48 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: "Brian F. Feldman" <green@FreeBSD.org> 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: <Pine.SUN.3.91.1010121175030.24988A-100000@pcnet1.pcnet.com> In-Reply-To: <200101212240.f0LMeSc20272@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Jan 2001, Brian F. Feldman wrote: > 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. Remember that this is already possible. Our current syscalls are _foo with foo being a weak definition to _foo. We currently use foo all over libc and noone seems to object until now. -- Dan Eischen 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?Pine.SUN.3.91.1010121175030.24988A-100000>