long double (was "strtold?")

[Jeff Johnston]

Hi Ken,

A number of comments:

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.
2) Put the _LDBL_EQ_DBL check in libc/include/machine/ieeefp.h
    (fix the SPE to manually #undef and then #define it to true in 
sys/config.h)
3) Add a license for the new files.  If it is copied from a file without 
a license, then mention which
    file it is copied from or add the Red Hat license from 
COPYING.NEWLIB which is the
    default license
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.
5) Some docs would be nice at least to state the group is only available 
when long double == double

-- Jeff J.

Ken Werner wrote:
> On Thursday 02 April 2009 00:32:45 Howland Craig D (Craig) wrote:
>   
>> A few questions and two suggestions.
>>
>> Why is the defined(__GNUC__) term included in the general #if that is
>> used?
>> (It was obviously needed in the previous aliasing approach, but I don't
>> see why it is present in this approach.)
>>     
>
> My bad - this is a relict of the former patch. Thanks for the heads up.
>
>   
>> Why do the libm source files all have w_ as a prefix?  (e.g. w_atanl.c)
>> (I have no idea why some of the existing source files are s_ and some
>> are
>> e_ and others are w_, along with other minor variations.  Do you know
>> the naming convention?)
>>
>> Regardless of the w vs. s vs. e, the names are not consistent with what
>> is presently there for float with respect to double.  For example,
>> s_atan.c and sf_atan.c.  If we were to follow the existing convention,
>> it should be wl_atan.c, for example.  Personally, I'd rather skip the
>> silly prefixes and just make it the function name, e.g. atanl.c.  I
>> propose that we do without the prefixes, starting clean for all of the
>> long double routines (at least in libm, where the names were done that
>> way).
>>     
>
> From looking at the sources it seems like w is for wrappers. Omitting the 
> prefix sounds reasonable. In case a platform wants to override existing math 
> routines there should be only one file for each routine. When implementing real 
> long double routines we probably don't want them to be flagged as wrappers 
> (assuming the overlay is done by matching the file names). The attached patch 
> skips the prefix.
>
>   
>> Should libm/common/Makefile.am perhaps have a new macro named lsrc to be
>> consistent with the present src and fsrc?
>>     
> Sounds good, I changed that too.
>
>   
>> Suggestion:  instead of always using the same big expression
>> +#if defined(__GNUC__) && (!defined(__STRICT_ANSI__) ||
>> defined(__cplusplus) || \
>> +     __STDC_VERSION__ >= 199901L) && (DBL_MANT_DIG == LDBL_MANT_DIG &&
>> \
>> +     LDBL_MIN_EXP == DBL_MIN_EXP && LDBL_MAX_EXP == DBL_MAX_EXP)
>>
>> define a shorter one that gets put into math.h.  For example:
>>
>> #if (!defined(__STRICT_ANSI__) || __STDC_VERSION__ > 199901L || \
>> defined(__cplusplus))  &&  defined(LDBL_MANT_DIG)  &&  \
>> 	(DBL_MANT_DIG == LDBL_MANT_DIG && \
>> 	LDBL_MIN_EXP == DBL_MIN_EXP && LDBL_MAX_EXP == DBL_MAX_EXP)
>>   #define _LDBL_EQ_DBL
>> #endif
>> [Notice that I added a check for LDBL_MANT_DIG being defined, as it
>> is possible for long double to not exist if it's a C89 compiler but
>> without STRICT_ANSI having been selected.  (This is my 2nd suggestion.)
>> Since we've assumed the presence of float.h, checking any of the LDBL
>> defines is the same as a configure check for AC_TYPE_LONG_DOUBLE.
>> No need for configure when float.h can be assumed.]
>>
>> Then, in all of the libm files (and a few places in math.h, itself):
>> #include <math.h>
>> #if defined(_LBDL_EQ_DBL)
>> ...
>> #endif
>>     
>
> The new patch defines _LBDL_EQ_DBL within _ansi.h because this header file is 
> included from both stdlib.h and math.h. Let me know if there is a better place 
> to put it.
>
>   
>> This is very similar to using AC_TYPE_LONG_DOUBLE_WIDER from one
>> place, but is doing it via float.h instead of configure.
>> In addition to being easier to read in the source files, it permits
>> an easy modification of the if for all of the source in 1 place
>> instead of needing to edit it in many, should the need ever arise.
>> (An interesting future possibility is if a system used, for example,
>> 128 bits for double and long double.  The present routines hard code
>> 64 or 32 bits for double.  So if at that time there were 128-bit LD
>> routines, _LDBL_EQ_DBL would not be defined, but _DBL_EQ_LDBL could
>> be, which would then map the double routines to the long double.  And
>> this will probably happen at about the same time that the US government
>> actually returns to a balanced budget.)
>>
>> I've been planning a LDBL_EQ_DBL define for the real long double
>> routines
>> that I'm working on, but have it in a math library local include.
>> "Promoting" it to math.h probably makes sense.
>>
>> A minor variation of the above is to also define something that says
>> long double ought to be used, where a potential user-configured choice
>> to not use long double even if it could be is also demonstrated:
>> #if (!defined(__STRICT_ANSI__) || __STDC_VERSION__ > 199901L || \
>> defined(__cplusplus))  &&  defined(LDBL_MANT_DIG)  &&  \
>> 	!defined(SKIP_LDBL)
>>   #define _USE_LDBL
>> #endif
>>
>> Then, in all of the libm files (and a few places in math.h, itself):
>> #include <math.h>
>> #if defined(_USE_LDBL) && defined(_LBDL_EQ_DBL)
>> ...
>> #endif
>> Or, down the road:
>> #if defined(_USE_LDBL)
>>  #if !defined(_LDBL_EQ_DBL)
>> 	real function
>>  # else
>> 	wrapper
>>  #endif
>> #endif
>> _USE_LDBL probably does not make sense in the source files, as would
>> make more sense to leave the LDBL source out of the makefiles.  But it
>> could make sense in header files.
>>     
>
> Why would anyone with a platform where there's no difference between double and 
> long double prefer the long double routine?
>
>   
>> Craig
>>     
> Thanks
> Ken
>
>