Date: Sat, 20 Jan 2001 16:02:53 -0800 From: Peter Wemm <peter@netplex.com.au> To: "Jacques A. Vidrine" <n@nectar.com> Cc: Daniel Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <200101210002.f0L02rk43575@mobile.wemm.org> In-Reply-To: <20010120153158.A88123@hamlet.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jacques A. Vidrine" wrote: > On Fri, Jan 19, 2001 at 07:38:00PM -0500, Daniel Eischen wrote: > [snip] > > Overview of the changes > > ----------------------- > > Thanks for the hard work and the great overview! > > 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). 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.. 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. There is nothing worse than the internal libc strdup() calling the internal malloc() and passing a pointer back for you to free with *your* free(). > 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). Yes! Something like what bind did with the resolver namespace? ie: if you 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. err() is another prime example as you point out. Things like sendfile() would have been good if they could have been handled this way too, but since that was prototyped in a common header (<sys/socket.h> if I recall correctly), it would not have made much difference for this one. > Thanks again & Cheers, > -- > Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 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?200101210002.f0L02rk43575>