Mail Archives: djgpp-workers/2003/12/29/17:23:25
--part1_10f.2a7e686e.2d22034c_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In a message dated 12/29/2003 4:49:15 PM Eastern Standard Time,
rich AT phekda DOT gotadsl DOT co DOT uk writes:
> My suggestion is to let the macros stand in ieeefp.h and
> >avoid their use via the patch to fdlibm.h.
> >
> >What do you think?
>
> How about adding is*f stubs to libm that call the macros defined in
> <math.h>. This is so that the isnan macro and the isnanf function both
> end up calling the appropriate variant of __fpclassify. (And similarly
> for the other is*f functions.) We'd convert the macro definitions in
> <ieeefp.h> to declarations similar to the ones in <math.h>.
>
This idea seems to have merit. Keep in mind that we have to keep the
definitions for the legacy users who do not include fdlibm.h but include ieeefp.h.
Sadly, ieeefp.h contains prototypes for same functions.
> OTOH it may be that is*f are macros in <ieeefp.h> for speed. So we could
> put static inline functions in that header. With this scheme, static
> inline functions may cause a clash between <math.h> and <ieeefp.h>, due
> to is*f being normal functions in <math.h> and inline in <ieeefp.h>. I
> guess we'd have to call the inlines something like __ieeefp_isnanf and
> then #define them to isnanf.
>
> How does that sound?
>
What's wrong with simply undefining the macros in fdlibm.h? The speed
element is a trivial consideration. It is the conflict with the library functions
that should be avoided. Moreover, the improper type casting that is causing
this grief remains in the macro.
--part1_10f.2a7e686e.2d22034c_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<HTML><FONT FACE=3Darial,helvetica><HTML><FONT SIZE=3D3 PTSIZE=3D12 FAMILY=
=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">In a message dated 12/29/2003 4:49:15=
PM Eastern Standard Time, rich AT phekda DOT gotadsl DOT co DOT uk 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"=
BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 PTSIZE=3D10 F=
AMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">My suggestion is to let the ma=
cros stand in ieeefp.h and <BR>
>avoid their use via the patch to fdlibm.h.<BR>
><BR>
>What do you think?<BR>
<BR>
How about adding is*f stubs to libm that call the macros defined in <BR>
<math.h>. This is so that the isnan macro and the isnanf function both=
<BR>
end up calling the appropriate variant of __fpclassify. (And similarly <BR>
for the other is*f functions.) We'd convert the macro definitions in <BR>
<ieeefp.h> to declarations similar to the ones in <math.h>.<BR>
</BLOCKQUOTE></FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKG=
ROUND-COLOR: #ffffff" SIZE=3D2 PTSIZE=3D10 FAMILY=3D"SANSSERIF" FACE=3D"Aria=
l" LANG=3D"0"><BR>
<BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D3 PTSIZE=3D12 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">T=
his idea seems to have merit. Keep in mind that we have to keep the de=
finitions for the legacy users who do not include fdlibm.h but include ieeef=
p.h. Sadly, ieeefp.h contains prototypes for same functions.<BR>
<BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D2 PTSIZE=3D10 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"=
><BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D2 PTSIZE=3D10 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"=
><BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">OTOH it may be that is*f are ma=
cros in <ieeefp.h> for speed. So we could <BR>
put static inline functions in that header. With this scheme, static <BR>
inline functions may cause a clash between <math.h> and <ieeefp.h&g=
t;, due <BR>
to is*f being normal functions in <math.h> and inline in <ieeefp.h&=
gt;. I <BR>
guess we'd have to call the inlines something like __ieeefp_isnanf and <BR>
then #define them to isnanf.<BR>
<BR>
How does that sound?<BR>
</BLOCKQUOTE><BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D3 PTSIZE=3D12 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><=
BR>
What's wrong with simply undefining the macros in fdlibm.h? The speed=20=
element is a trivial consideration. It is the conflict with the librar=
y functions that should be avoided. Moreover, the improper type castin=
g that is causing this grief remains in the macro.</FONT></HTML>
--part1_10f.2a7e686e.2d22034c_boundary--
- Raw text -