X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f From: Kbwms AT aol DOT com Message-ID: <10f.2a7e686e.2d22034c@aol.com> Date: Mon, 29 Dec 2003 17:23:08 EST Subject: Re: isnanf et al To: djgpp-workers AT delorie DOT com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_10f.2a7e686e.2d22034c_boundary" X-Mailer: 8.0 for Windows sub 6021 Reply-To: djgpp-workers AT delorie DOT com --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 > . 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 > to declarations similar to the ones in . > 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 for speed. So we could > put static inline functions in that header. With this scheme, static > inline functions may cause a clash between and , due > to is*f being normal functions in and inline in . 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 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 ma= cros 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>.


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.



OTOH it may be that is*f are ma= cros 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&g= t;, due
to is*f being normal functions in <math.h> and inline in <ieeefp.h&= gt;. I
guess we'd have to call the inlines something like __ieeefp_isnanf and
then #define them to isnanf.

How does that sound?

<= 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. --part1_10f.2a7e686e.2d22034c_boundary--