Date: Mon, 22 Jan 2001 21:40:52 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Wemm <peter@netplex.com.au> Cc: "Jacques A. Vidrine" <n@nectar.com>, Daniel Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <Pine.BSF.4.21.0101222102230.28114-100000@besplex.bde.org> In-Reply-To: <200101210002.f0L02rk43575@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 20 Jan 2001, Peter Wemm wrote: > "Jacques A. Vidrine" wrote: > > I have one objection: > > > > [snip] > > > _thread_sys_foo - actual syscall > > > _foo - weak definition to _thread_sys_foo > > > foo - weak definition to _thread_sys_foo > > > > > > I've changed all the instances of foo() to _foo() in libc for > > > those hidden system calls. Anyone modifying or adding to libc > > > will have to be careful to use the same conventions. > > > > Please, no. Kill `un-namespace' and let us continue to use the > > correct name for `foo'. Adding underscores in front of lotsa common > > calls hurt my eyes and hinders porting between different libc > > implementations (e.g. our `old' one, other *BSDs). I think it would be more confusing without the explicit underscores. The library really does call the underscored versions. To debug it you need to put breakpoints at the underscored versions... > Hmm. I went through the diff looking for reasons why we needed the > un-namespace.h stuff and to use the _ prefix, but now I am not sure. I > suspect we probably should add the _ characters and leave the #defines > active. Unless I missed something.. namespace.h is an evil hack (#defining names in the implementation namespace gives undefined behaviour, and can cause problems even for the implementor). un-namespace.h is to limit this hack to headers and prevent future unintentional dependencies on it. > On the subject of namespace etc, I wish this went further. Consider > malloc(). We provide a strong 'malloc' symbol. I think it would be better > if we provided _malloc(), _free(), _calloc() and a weak malloc->_malloc > pointer etc. This way if the user process provides an alternative malloc, > then libc and everything else should use the one single malloc. I helped implement this for the Minix libc many years ago. Not many people seem to care about it in practice. There is (was?) a Linux distribution that made a marketing point about it. glibc is careful about it. > > Finally, I hope this will lead us into introducing all non- Standard C > > (or at least non-POSIX) function identifiers in the same fashion, so > > as to clean up our namespace. For example, err(3). Jacques' nsswitch changes broke static linkage by calling the err() family from libc. I have uncommitted fixes. Recent crypto changes broke static linkage in several ways, one involving namespace collisions. > Yes! Something like what bind did with the resolver namespace? ie: if you Hopefully nothing like what bind did :-). Bind shows how not to do it. > want to use the res_foo() functions, you must #include <resolv.h> in order > to get the prototypes and the #define res_foo __res_foo into scope. This > stops res_foo() in libc conflicting with your res_foo() in your program. This results in no library functions name res_foo actually being in your program. The following things break: 1) #undef'ing res_foo. ISTR that the Standard C library explicitly permits #undef'ing the names of most standard functions (ones which are documented as being macros only). You might want to do this for simpler debugging. 2) Calling (res_foo). The parentheses prevent the macro be expanded, and there should be a backing function. I'm sure Stdnard C permits this for most functions. 3) Putting a breakpoint at res_foo in a debugger. 4) Utilities that check things related to res_foo. I have a man page checker that reads the prototype for res_foo from its man page and checks that this matches one in the the headers documented in the man page. This fails because there is no prototype for res_foo in the headers, only one for __res_foo. Bruce 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.BSF.4.21.0101222102230.28114-100000>