long double (was "strtold?")

Howland Craig D (Craig) howland@LGSInnovations.com
Tue Apr 7 21:35:00 GMT 2009


Jeff Johnston wrote Monday, April 06, 2009 6:30 PM:
>
> 1) Use _LONG_DOUBLE instead of long double everywhere
>     The PPC SPE for example redefines _LONG_DOUBLE to be double in 
> sys/config.h
>     Other platforms are allowed to do this.

_LONG_DOUBLE is presently used only in libc.  It has two very slightly
different uses that I saw that are only minor distinctions of the same
thing.  The first is to allow for a non-ANSI compiler (which presumably
would not have the long double type).  The second is (presumably) to
allow
for an ANSI compiler that does not have long double (of which
sys/config.h
is an example).  In both cases, the lack of long double produces a
mapping
(redefining, not typedef) of long double to double.  To be more precise
about where it is used, the only _LONG_DOUBLE uses appear to be for the
printf and scanf families.
 
However, this makes sense if only printf and scanf are being
considered--I don't think that it makes sense once the math library is.
In a libm source file for ceill(), for example, why would you ever want
to allow it to compile as double ceill()?  Thinking generally--not
Newlib's current state--there are three possible cases at compile time:
1)  double==long double,
2)  double!=long double, and
3)  long double does not exist.
In cases 1 & 2, the libm functions want to be long double type.  In the
first case the function degenerates to a wrapper that calls the
respective double function (which is what Ken's patch is providing to
start with--we don't want to have a lengthy function x() and an
identical
lengthy function xl()), but it still should be long double type.  If the
long double type does not exist (#3), then the libm long double
functions
should never be compiled.  (As opposed to print/scan, the whole function
wants to go away, rather than modifying behavior in a small part of a
larger function.)
 
I propose that rather than needing to introduce _LONG_DOUBLE into any
of the libm source files, that the libm makefile needs a conditional to
skip them if long double does not exist.  (We could use a back-door
method
of #if defined(LDBL_MAX) (or some such) to empty the source files if
long
double didn't exist, but it would be cleanest to skip making the
files and avoid putting empty objects into the library.)  This makes it
clear that the libm functions are different than the libc functions--the
former do not want to be used if LDBLs do not exist, while the latter
(preexisting) ones have a compatibility mode.  I'll even go so far as
saying that a future step would be to change the libc stuff to an
explicit
#if HAVE_LDBL style instead of the present implicit mapping method.
(Which I would be happy to do later.)
 
Does this make sense, or have I missed something?


> 4) If these functions will ever be implemented, they will probably end

> up in libm/math, not libm/common
>      If Craig doesn't mind doing this when he implements them, I have
no 
> objections.
 
I wouldn't mind moving things as we add the "real" versions, but it
makes more sense to start them out where you prefer them to be.
This would also be more friendly to people adding machine-specific
versions of functions before the generic ones come along.
 
A follow-up question:  what's the difference between math and
common, anyway?  (Given that mathfp is abandoned, aren't they all
effectively common, anyway?  Or is this why you want them in math,
because mathfp is gone and all common should really be in math?)
 
Craig



More information about the Newlib mailing list