This is the mail archive of the libc-alpha@sourceware.org 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: C floating-point bindings as API sources


On Wed, 11 Nov 2015, Szabolcs Nagy wrote:

> > Are you saying that you personally are OK with these APIs for glibc, but
> > suppose that hypothetically some other people might object on grounds of
> > code size?
> > 
> 
> yes
> (others might also object because of the maintenance burden).

I think new functions written consistently, at the same time, with an eye 
to current IEEE semantics and glibc's documented accuracy goals, by 
someone familiar with libm function implementation issues, are likely to 
have a substantially lower maintenance burden than the accumulation of 
existing functions from a range of sources, written by a range of people 
in different contexts, not just for glibc (so likely with different goals, 
not that glibc had defined accuracy goals at the time), and adapted to 
different floating-point types over time.  (For part 3 you are of course 
dealing with the range of existing function implementations, adjusted for 
different type names, but careful design still helps a lot there.)

It's true that it's important to think carefully about such design issues 
before working on implementation, to agree with the community on choices 
made, and to have a good global view of glibc libm issues and of TS 18661 
when doing so.  Hence my warnings in the discussion of *f128 for powerpc 
support that, while I approve in principle of adding the feature, just 
jumping in to copy lots of files in the first implementation approach that 
comes to mind would be a bad idea and not likely to reach consensus for 
the resulting patches.

> i haven't counted but i think there are >150 new math functions
> in part 2 and part 4 (considering float, double and long double)
> which i think is significant enough to justify my hypothesis.

I assume you mean part 1 not part 2 (since part 2, decimal floating-point, 
is not part of my proposal).  The natural comparison is with the functions 
added in C99.  I count 66 <complex.h> functions in C99 (all new), 11 
<fenv.h> functions (all new) and 171 <math.h> functions (plus type-generic 
macros not included in that figure) compared to 22 <math.h> functions in 
C90, i.e. 226 new libm functions (plus new macros and a few relevant libc 
functions such as strtold) in C99.

-- 
Joseph S. Myers
joseph@codesourcery.com


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