On Wed, Feb 25, 2009 at 03:21:34PM +0100, Bernd Schmidt wrote: >Denys Vlasenko wrote: >> On Wednesday 25 February 2009 01:31:01 pm Bernd Schmidt wrote: >>> [email protected] wrote: > >>>> reinstate __libc_foo for linuxthreads.old >>> The code didn't seem to have the awful #ifdefs before your checkins >>> 24362 and 24363. I think it's a terrible idea to add more differences >>> between pthreads versions like this. >> >> Without ifdefs, __libc_foo's will exist even in non-threaded builds. >> I prefer this to not happen. I feel it is cleaner to minimize >> the number of non-standard names being exported. > >Anything starting with a double underscore is in the libc namespace, so >this isn't something we need to worry about.
Well for cleanness it is preferable not to export "artificial" symbols that are not mandated by a sensible standard iff it is a voidable. > >> Did it really get seriously worse? Let's compare: >> >> 0.9.30: >> >> extern __typeof(write) __libc_write; >> #define __NR___libc_write __NR_write >> _syscall3(ssize_t, __libc_write, int, fd, const __ptr_t, buf, size_t, count) >> libc_hidden_proto(write) >> weak_alias(__libc_write,write) >> libc_hidden_weak(write) >> >> Trunk: >> >> _syscall3(ssize_t, write, int, fd, const __ptr_t, buf, size_t, count) >> #ifndef __LINUXTHREADS_OLD__ >> libc_hidden_def(write) >> #else >> libc_hidden_weak(write) >> strong_alias(write,__libc_write) >> #endif > >It means that write will change from being a strong to a weak definition >depending on which threads library you select, which is surprising. All >#ifdefs add the risk of bugs being added in the future since you'll >typically only ever compile one branch. > >>> Besides, shouldn't these functions be weak in any case, so that the user >>> can override them? >> >> Ordinarily, libc interface functions are not weak. > >That's something that one of these days I'd really like a definite >answer to. Some gcc tests rely on being able to override certain libc >functions. Which tests? Do you have a sample at hand? _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
