RE: long double (was "strtold?")

["Howland Craig D (Craig)" <howland at LGSInnovations dot com>]

Jeff said:
>We can expose the prototypes for all platforms that support long
double,
>but there will be disappointment when they don't link because they are
>not implemented in general.
I've actually been thinking about this a bit, recently.  Many of the
include files are so hard to follow, that rather than attempting to read
them to figure out what supposedly is supplied, it can be much easier to
compile and link to find out.  Linking is the real answer, anyway, as
there are also potentially mistakes with missing prototypes or even
extra ones.  And unless most users use GCC -Wmissing-prototypes (or
equivalent)--which is not by default nor part of -Wall--they won't know
if they have the prototypes or not.  I've actually been thinking that
we perhaps should clean up the headers a lot by getting rid of so
much conditional stuff and reducing it to bare bones.  If you don't
violently object to the idea, I will start a separate email thread on
the subject with some suggestions and justifications.  (It's on a list
of things that I've been meaning to do at some point, but since it
was brought up, it seems like now is maybe the time.)

>> The need for stdlib.h and math.h to gate the prototypes should only
be
>> temporary, as when the "real" LDBL routines get added they come out
of
>> the gate--which eventually disappears.
>>
>> One thought is that perhaps to avoid a lot of angst over something
that
>> is only temporary, put the works-only-with-GCC check into config.h.
If
>> someone wants the benefit with other than GCC, they can manually
>> define _LDBL_EQ_DBL flag in config.h.
Ken said:
>That would be fine for the SPU since the XLC defines __LDBL_MANT_DIG__
and
>friends too. I can't speak for other compilers out there.
Jeff said:
>Putting Ken's only-with-gcc check in libc/sys/config.h accomplishes
this
>as it will turn both flags on but it still allows a platform to expose
>the prototypes and implement the function specifically for the platform
>(e.g. done via special hardware insns).

The more compliers that match the GCC sytax, the fewer chances that
someone would need to manually request.  It sure sounds like this is
the least work.  Maybe we should just do this alternative instead of
the following one (unless we think there is a real advantage to the
changeable long double size detection).

>
>> Another thought is that the check should really just be run by
>> configure,
>> and _LDBL_EQ_DBL gets put into something that configure generates,
>> as in newlib.h.  (In certain respects this is perhaps best, as it
>> records
>> what the library was built with in case the user has a compiler
option
>> that changes long double size.  I did see that in the forthcoming GCC
>> 4.4 that there seems to be an option for SW FP to use 128 bits vs. a
>> default smaller size.)
>
Ken said:
>I played with the AC_TYPE_LONG_DOUBLE_WIDER macro but there are two
things to
>consider. We would need to upgrade the autoconf version required by
newlib and
>introduce something like config.h (through AC_CONFIG_HEADERS). which
might
>pollute the name space if it get's pulled by a standard header.
>
Jeff said:
>I think an executable test is required to accomplish this which can't
be
>done in newlib due to the missing library at time of configure.

Ken's former problem could easily be circumvented by writing our own
test
as he did for HAVE_LONG_DOUBLE, couldn't it?  Something like:

cat >conftest.c <<EOF
#include <float.h>
#if DBL_MANT_DIG == LDBL_MANT_DIG  &&  LDBL_MIN_EXP == DBL_MIN_EXP  &&
\
    LDBL_MAX_EXP == DBL_MAX_EXP
  #define _LDBL_EQ_DBL
 #else
  #error "LDBL != DBL"
#endif
EOF

(Of course, the #define is meaningless, but I just copied what we have
already and did a minimal amount of editing.  Maybe a declaration would
be needed in case there were any compilers that didn't like to make
empty objects.)

This is not an executable test that needs the library, as float.h comes
from the compiler.  It just takes a compile-only pass/fail.  So I think
that it is viable, should we decide on this as the best alternative.

I don't understand Ken's latter comment about name space pollution.
Could
you elaborate?
 
Craig