delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/09/29/11:02:33

X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
From: Kbwms AT aol DOT com
Message-ID: <2d.3476c521.2ca9a356@aol.com>
Date: Mon, 29 Sep 2003 11:01:42 EDT
Subject: Re: Integrating K. B. Williams's maths functions
To: djgpp-workers AT delorie DOT com, eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
CC: rich AT phekda DOT freeserve DOT co DOT uk
MIME-Version: 1.0
X-Mailer: 8.0 for Windows sub 6015
Reply-To: djgpp-workers AT delorie DOT com

--part1_2d.3476c521.2ca9a356_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 9/29/2003 1:23:11 AM Eastern Standard Time, 
eliz AT elta DOT co DOT il writes:

> >>I think when these functions are part of libc.a, we should remove the
> >>ones in libm.a.
> >
> >The point is that neither library has a nan() function that meets C99
> >specifications -- namely that the C99 functions take a calling-sequence
> >parameter whereas the current ones to not.  What should we do about that?
> 
> I thought Richard wrote a version of `nan' that does support C99's
> semantics.
> 

A scan of libm.a reveals that none of its functions uses nan().  The function 
is used extensively, as is nanf(), in the test generators in subdirectory 
../tgen, however.  The code for these functions can easily be copied and used 
separately.


KB Williams

--part1_2d.3476c521.2ca9a356_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D3 FAMILY=3D"SERIF" FACE=3D"=
Georgia" LANG=3D"0">In a message dated 9/29/2003 1:23:11 AM Eastern Standard=
 Time, eliz AT elta DOT co DOT il writes:<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT><FONT  COLOR=3D"#000000"=
 style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"A=
rial" LANG=3D"0">&gt;&gt;I think when these functions are part of libc.a, we=
 should remove the<BR>
&gt;&gt;ones in libm.a.<BR>
&gt;<BR>
&gt;The point is that neither library has a nan() function that meets C99<BR=
>
&gt;specifications -- namely that the C99 functions take a calling-sequence<=
BR>
&gt;parameter whereas the current ones to not.&nbsp; What should we do about=
 that?<BR>
<BR>
I thought Richard wrote a version of `nan' that does support C99's<BR>
semantics.<BR>
</BLOCKQUOTE><BR>
</FONT><FONT  COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3=
 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><BR>
A scan of libm.a reveals that none of its functions uses nan().&nbsp; The fu=
nction is used extensively, as is nanf(), in the test generators in subdirec=
tory ../tgen, however.&nbsp; The code for these functions can easily be copi=
ed and used separately.<BR>
<BR>
<BR>
KB Williams</FONT></HTML>

--part1_2d.3476c521.2ca9a356_boundary--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019