This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] Add generic HAVE_RM_CTX implementation

On Mon, 12 May 2014, Wilco wrote:

> > Shouldn't this be __fegetenv and __fesetround?  We shouldn't need to
> > go through the extra dereference since these functions are
> > internal-only.  Likewise for all uses below.
> I agree we should avoid PLTs for internal calls. However I'm certain
> most targets wouldn't build if I used __fegetenv etc. libm_hidden_ver
> is used inconsistently, so this is yet another area that needs a cleanup.

As I said in <>, 
PLT avoidance (via hidden_def etc.) is a separate matter from 
namespace-cleanness (via __-prefixed names).

I think you can assume that for the symbols with libm_hidden_proto in 
include/fenv.h, all architectures use libm_hidden_def (otherwise they'd 
have had obvious build failures, at least if the symbol is in fact used 
internally).  *But*, if you want to use an __-prefixed name, you need to 
make sure all architectures do in fact define that name and then use a 
weak alias for the public name, as they may well not be consistent in that 
regard.  And it may still be useful to declare that __-prefixed name as 
hidden (i.e. use attribute_hidden on the prototype) or use hidden_proto / 
hidden_def with it; I'm not sure how important any compile-time 
optimizations this enables are, but it does allow for such optimizations 
at compile time rather than just at link time.

Namespace-cleanness is an issue here when the functions get used from C90 
libm functions, since C90 doesn't include the <fenv.h> functions (I expect 
it's also a pre-existing bug there and so any fix should include a bug 
report in Bugzilla, etc.) - C90 functions shouldn't use the fe* names (or 
a reserved name that brings in a non-reserved name as a *strong* alias).  
It's not relevant for calls from non-C90 functions (e.g. those for float 
and long double) except where in some other standard that lacks the 
<fenv.h> functions (e.g. Unix98 has some of the C99 functions for double).  
But in practice it would be fragile to rely on which math_private / 
fenv_private facilities get called from which libm functions, so I think 
systematically using the __-* names should be the eventual goal.

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]