From: <ams AT ludd DOT luth DOT se>
Message-Id: <200304221819.h3MIJuOH013058@speedy.ludd.luth.se>
Subject: Re: Yet another try on nan in strto{f,d,ld}
In-Reply-To: <3EA53D71.79DFB503@phekda.freeserve.co.uk> "from Richard Dawe at
 Apr 22, 2003 02:02:41 pm"
To: djgpp-workers AT delorie DOT com
Date: Tue, 22 Apr 2003 20:19:55 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-MailScanner: Found to be clean
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Richard Dawe:
> > 4. I haven't changed _strtold()'s documentation. Should we really have
> > the exact same documentation twice (except the portablity notes)? In
> > the same file too?! There must be a better way to do this.
> 
> This is an issue with many other parts of the documentation. Until we come to
> a decision, I think you should make the same edits to both files.
> 
> The alternatives are:
> 
> 1. duplicate the description between similar functions;
> 2. have one description as the definite one and refer (@(|x|px)ref) to that
> from the other ones;
> 3. put the description in another file and @include it in all the relevant
> pages.

Couldn't we have both functions described on the same page, but with
different @port-notes?

Something like:

#include <stdlib.h>

long double strtold(const char *s, char **endp);
long double _strtold(const char *s, char **endp);

Description

This function converts ...

<Some magic (today probably not implemented) @port-notes here that
differentiates the two functions.>

?

> > Index: djgpp/src/libc/ansi/stdlib/strtold.c
> [snip]
> > +          n.mantissal = mantissa_bits & 0xffffffff;
> > +         n.mantissah = (mantissa_bits >> 32) & 0xffffffff;
> 
> The indentation looks inconsistent here.

Indeed. Looks in this mail. The code looks fine. It seems my emacs
inserts tabs when I tabify to make the lines line up. Is that a
problem?

> Apart from that, the patch looks good to me. But I think you need to answer
> Eli's concerns about FP emulation, before an updated patch can go in.

"FP emulation"? You mean unmasking of the signal, right? (Otherwise
there's some mail missing. I haven't managed to mail or forward
my answers to Eric Rudd(?)'s complaints about div() on the djgpp
newsgroup. I've got no bounces either.)


Right,

						MartinS