Date: Mon, 22 Jan 2001 05:27:47 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Bruce Evans <bde@zeta.org.au> 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.1010122051818.17483B@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0101221935540.27700-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Jan 2001, Bruce Evans 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.
>
> (1) Underscores are verbose and ugly.
> (2) _foo is usually sufficient. _[a-z] is not entirely in the user
> namespace like you are claimed. From the 1990 ISO standard:
> "All identifiers that begin with an underscore are always
> reserved for use as identifiers with file scope in both the
> ordinary identifier and tag name spaces". In practice, this
> means that the implementation can use names beginning with
> _[a-z] except for macro names and global variables that are
> used in macros. E.g., errno must be defined as (*__error())
> and not as (*_error()), since the latter would break the
> standard-conforming application code:
> #include <errno.h>
> void foo(void) { int _error = errno; }
> A single underscore is sufficient in all other cases. E.g.,
> struct member names are in a nested namespace so they don't
> conflict with variable names at all. They may still need a
> single underscore so that they don't conflict with macro
> names.
> (3) We have some precedence for using _foo.
> (4) NetBSD uses _foo (at least in old versions).
How about this compromise: __sys_foo(T), _foo(W), foo(W).
Noone but libc_r, except perhaps for exit.c, needs to reference
__sys_foo.
Poking around with nm on Solaris seems to show that they use
__foo for system calls, and _bar for library functions.
--
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.1010122051818.17483B>