From owner-freebsd-arch Mon Jan 22 2:41:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8F1F537B402 for ; Mon, 22 Jan 2001 02:41:15 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA28853; Mon, 22 Jan 2001 21:40:58 +1100 Date: Mon, 22 Jan 2001 21:40:52 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Wemm Cc: "Jacques A. Vidrine" , Daniel Eischen , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: <200101210002.f0L02rk43575@mobile.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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