delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/09/28/17:07:26

X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
From: Kbwms AT aol DOT com
Message-ID: <12e.322be914.2ca8a773@aol.com>
Date: Sun, 28 Sep 2003 17:06:59 EDT
Subject: Re: Integrating K. B. Williams's maths functions
To: djgpp-workers AT delorie DOT com, 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_12e.322be914.2ca8a773_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Rich Dawe and Eli Zaretskii:

In a message dated 9/28/2003 4:29:30 PM Eastern Standard Time, 
eliz AT elta DOT co DOT il writes:

> >Date: Sun, 28 Sep 2003 20:01:59 +0100
> >From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> >
> >> >There are functions in libm.a, namely nan() and nanf(), that conflict 
>> with
>> >those in C99 because the libm.a functions do not take an argument.  What 
>> are
>> >our plans for developing C99 versions of these functions?
>> 
> 
> >My plan is that we will use those rather than those in libm.a.
> 
> 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?


KB Williams

--part1_12e.322be914.2ca8a773_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">Rich Dawe and Eli Zaretskii:<BR>
<BR>
In a message dated 9/28/2003 4:29:30 PM Eastern Standard Time, eliz AT elta DOT co.=
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;Date: Sun, 28 Sep 2003 20:01:59 +0100<BR>
&gt;From: Richard Dawe &lt;rich AT phekda DOT freeserve DOT co DOT uk&gt;<BR>
&gt;</FONT><FONT  COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=
=3D3 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><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;There are functions in libm.a, namely nan() and nanf(),=
 that conflict with<BR>
&gt;those in C99 because the libm.a functions do not take an argument.&nbsp;=
 What are<BR>
&gt;our plans for developing C99 versions of these functions?<BR>
</BLOCKQUOTE><BR>
<BR>
&gt;My plan is that we will use those rather than those in libm.a.<BR>
<BR>
I think when these functions are part of libc.a, we should remove the<BR>
ones in libm.a.<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>
The point is that neither library has a nan() function that meets C99 specif=
ications -- namely that the C99 functions take a calling-sequence parameter=20=
whereas the current ones to not.&nbsp; What should we do about that?<BR>
<BR>
<BR>
KB Williams<BR>
</FONT></HTML>
--part1_12e.322be914.2ca8a773_boundary--

- Raw text -


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