Re: long double (was "strtold?")

[Jeff Johnston <jjohnstn at redhat dot com>]

Howland Craig D (Craig) wrote:
> [This email has a new subject to branch off the "strtold?" email since
> it
> is asking some more general questions.]
>
> Corinna:
>      I've been wondering about the general long double issue recently
> because I was doing some preliminary work on adding some long double
> functions to the math library.  (I hadn't stumbled across ldtoa.c, yet,
> so
> it's interesting to learn of its existence.)
>   
Regarding why strtold isn't exposed.: there was a reason, but I can't 
for the life of me
remember.  It may no longer be relevant.  I'll keep pondering.
>      A question that I have had is, do long double functions need to
> have a configure check for long double for conditional inclusion?
> (I had gotten as far as finding out that configure has a built in check
> for it and that AC_TYPE_LONG_DOUBLE can be used to generate a define for
> HAVE_LONG_DOUBLE.  There's also AC_TYPE_LONG_DOUBLE_WIDER to generate
> HAVE_LONG_DOUBLE_WIDER so that we could know not to bother with
> separate routines from double.  I hadn't gotten far enough along to ask
> the mailing list.  But since you've brought up the general topic, this
> seems like a good time to ask.)
>   
The long double type flag check is a reasonable thorough thing do from 
the start but as you have pointed out,
ldtoa.c doesn't make the check and there haven't been any reported 
problems.

If the platform defines long double as double the functions should be 
provided for
portability reasons.  We obviously don't need to compile the long double 
specific code but there should be something along the lines of the 
_DOUBLE_IS_32BITS stuff.  You may have meant this above but I wanted to 
clarify.
>      A similar question arises as to whether we can assume that float.h
> is present.
>   
I think this is a reasonable assumption that hasn't proven to be broken 
in the past.  It is used by the printf/scanf families now without checks.
>      I see that ldtoa.c assumes the presence of both long double and
> float.h, so perhaps that has set the precedent that no checks are
> needed.
>      Another general question:  since long double is inherently an
> ANSI/ISO C type (having been introduced in C99), can the non-ANSI
> compiler
> nonsense be dispensed with when implementing any functions which use
> long double?  (That is, can the _EXFUN/_DEFUN stuff be skipped going
> forward with long double stuff?)  It would be so much easier to look at
> and less work to create and maintain.  I have taken this approach in the
> long double math library routines that I've done so far, although I had
> been assuming that they'd need to be gated with
> #if defined(HAVE_LONG_DOUBLE) just to guard against compilers that might
> not have long double (small microcontrollers, for example) even though
> they are otherwise ANSI/ISO.
>   
I want the _EXFUN and _DEFUN used for another reason.  It allows adding 
special
directives to all prototypes or definitions in one spot.
>      (By the way, so far for the math library I have ceill, floorl,
> nearbyintl, rintl, truncl, fpclassify, and some of the other similar
> easy ones.  They basically function but need polish.  I will need some
> kind of help for the numerical (e.g. sine, log) functions as I don't
> know enough to write them.  Anyone who'd like to help, let me know.)
>   
It can definitely be a can of worms regarding accuracy as the mathfp 
experiment has proven.

A number of the libm routines were originally taken from Sun.  You might 
want to check if there are
already long double versions out there from Sun if you haven't already 
done so.
>      Perhaps this email is creating a branch off your starting topic and
> should have the subject changed to separate them, but I wasn't sure how
> much traffic it would make on its own, so I didn't do so, yet.
> 				Craig
>
>   
-- Jeff J.
> -----Original Message-----
> From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
> On Behalf Of Corinna Vinschen
> Sent: Tuesday, March 10, 2009 1:54 PM
> To: newlib@sourceware.org
> Subject: strtold?
>
> Hi,
>
> I'm just implementing wscanf and friends.  While I'm at it, I'm
> stumbling over the missing wcstold functionality.  Strange enough,
> newlib has a strtold function in libc/stdlib/ldtoa.c.  However, that
> function is actually called _strtold and not mentioned in the header
> files at all.  But it's used in vfscanf.c.
>
> Here's the question:  Why is strtold not "officially" exported when
> the function is actually available?  Is there any good reason?
> If not, I'd suggest to declare strtold in stdlib.h.  Then I could
> implement wcstold along the lines of the current wcstod function and
> we would get long double support in wscanf more or less for free.
>
>
> Corinna
>
>