X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Subject: Re: Function nan()
From: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
To: djgpp-workers AT delorie DOT com
Cc: Kbwms AT aol DOT com
In-Reply-To: <1858-Fri04Jan2002110639+0200-eliz@is.elta.co.il>
References:  <200201032140 DOT WAA06212 AT father DOT ludd DOT luth DOT se> 
	<1858-Fri04Jan2002110639+0200-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0 (Preview Release)
Date: 04 Jan 2002 14:57:33 +0100
Message-Id: <1010152654.19897.4.camel@bender.falconsoft.be>
Mime-Version: 1.0
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

On Fri, 2002-01-04 at 10:06, Eli Zaretskii wrote:
> > From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
> > Date: Thu, 3 Jan 2002 22:40:48 +0100 (MET)
> > 
> > Can tagp make a signaling NaN?
> 
> That's not an important question right now; if my message somehow
> caused this to be an issue, I'm sorry.  I didn't mean to say that we
> should support SNaN, I wanted to say that the optional tag string
> could cause nan and strtod to produce one of the several bit patterns
> defined by IEEE and Intel for a NaN.
> 
> What I'm wondering is (a) whether this is a correct interpretation of
> the C9x standard, and (b) what strings are supported by other
> implementations (so we could be compatible to some extent).
> 
> I looked on a GNU/Linux machine, but unfortunately, glibc.info does a
> bad job of documenting what it does with that string: it simply
> repeats the standard's wording, including the ``implementation-defined''
> part(!).  Why the heck does it make sense to say in the docs of a
> specific implementation that some behavior is ``implementation-defined''?
> 
Well, glibc 2.1.3 has this as nan():

double
__nan (const char *tagp)
{
  if (tagp[0] != '\0')
    {
      char buf[6 + strlen (tagp)];
      sprintf (buf, "NAN(%s)", tagp);
      return strtod (buf, NULL);
    }

  return NAN;
}


Looking in strtod(), you have

  if (TOLOWER (c) == L_('n') && STRNCASECMP (cp, L_("nan"), 3) == 0)
  {
    /* Return NaN.  */
    FLOAT retval = NAN;

    cp += 3;
    /* Match `(n-char-sequence-digit)'.  */
    if (*cp == L_('('))
    {
      const STRING_TYPE *startp = cp;
      do
	++cp;
      while ((*cp >= L_('0') && *cp <= L_('9'))
       || (TOLOWER (*cp) >= L_('a') && TOLOWER (*cp) <= L_('z'))
       || *cp == L_('_'));
      if (*cp != L_(')'))
	/* The closing brace is missing.  Only match the NAN
	   part.  */
	cp = startp;
      else
	{
	  /* This is a system-dependent way to specify the
	     bitmask used for the NaN.  We expect it to be
	     a number which is put in the mantissa of the
	     number.  */
	  STRING_TYPE *endp;
	  unsigned long long int mant;

	  mant = STRTOULL (startp + 1, &endp, 0);
	  if (endp == cp)
	    SET_MANTISSA (retval, mant);
	}
    }
    if (endptr != NULL)
      *endptr = (STRING_TYPE *) cp;
    return retval;
  }