Date: Sat, 20 Jan 2001 21:57:49 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Peter Wemm <peter@netplex.com.au> Cc: "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.1010120213042.8121A-100000@pcnet1.pcnet.com> 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: > > On Fri, Jan 19, 2001 at 07:38:00PM -0500, Daniel Eischen wrote: > > > _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.. At one point, I was convinced that I also needed #pragma weak _foo (which would have gone in un-namespace.h) in order to force weak _references_ to _foo and to make it work correctly in static libraries. This was the problem with the non MT-safe libgcc.a being included in libstdc++. If libstdc++ was linked into a threaded program, it prevented libgcc_r from being pulled in because libstdc++ already included the symbols that were needed (from the non MT-safe libgcc). This was solved by using a libgcc that used weak references to the pthread routines, so that if the threads library was linked in, the pthread_foo references would be non-null and libgcc would then know to use them to make it MT-safe. JDP convinced me that we didn't need to use weak references and I pulled these pragmas out of un-namespace.h. Once thing that I have just added to un-namespace.h are the prototypes to _sigaction, _kevent, and _flock which can't be defined. I do something like this in un-namespace.h: #ifdef _SIGNAL_H int _sigaction(int, const struct sigaction *, struct sigaction *); #endif As for leaving un-namespace.h active, I'd prefer not to and explicity use the _ characters. Some things can't be defined and we need to explicity use their underscored versions. > 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. This was one of the things I was thinking about too. > 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. I'm all for making other changes, but I'd first like to get these changes committed before trying to come up with an all-encompassing patch set that everyone can agreee on ;-) -- 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.1010120213042.8121A-100000>