long double (was "strtold?")

[Ken Werner]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: longdouble.patch
Type: text/x-patch
Size: 30332 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20090402/0e16c523/attachment.bin>