Hi > >> > I would propose to define errno always by __errno_location > independently > >> of THREADS enabled/disabled (similarly h_errno and res_state). > >> > >> the point is to not have the overhead of an indirect pointer in the > >> non-threaded case. are you suggesting we force that overhead when it > >> is unnecessary ? > > > > yes > > then i'd say find a different way. it cant be that hard to hide the > indirection in a header with CPP. > now that I look closer, the #define h_errno (*__h_errno_location ()) is already unguarded by THREADS since a commit for NPTL, see below
commit d21497f9fba95688e464ae712bd6b4c0fbc4ea13 Author: Austin Foxley <[email protected]> Date: Sat Sep 19 09:54:20 2009 -0700 include/: add tls errno and res_state Signed-off-by: Austin Foxley <[email protected]> diff --git a/include/netdb.h b/include/netdb.h index 99e02f0..9d3807d 100644 --- a/include/netdb.h +++ b/include/netdb.h @@ -54,21 +54,38 @@ __BEGIN_DECLS /* Error status for non-reentrant lookup functions. - We use a macro to access always the thread-specific `h_errno' variable. - We always need the extern int here in case internal libc code undefines - the macro because it needs access to the underlying storage. */ -extern int h_errno; -#ifdef __UCLIBC_HAS_THREADS__ -# define h_errno (*__h_errno_location ()) -#endif + We use a macro to access always the thread-specific `h_errno' variable. */ +#define h_errno (*__h_errno_location ()) and the same for _res diff --git a/include/resolv.h b/include/resolv.h index fc2fa9b..e0cd35d 100644 --- a/include/resolv.h +++ b/include/resolv.h @@ -279,14 +279,10 @@ struct res_sym { /* 0x00008000 */ /* Things involving an internal (static) resolver context. */ -#if 0 __BEGIN_DECLS extern struct __res_state *__res_state(void) __attribute__ ((__const__)); __END_DECLS #define _res (*__res_state()) -#else -extern struct __res_state _res; -#endif only errno is kept special for disabled THREADS Peter -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
