Mail Archives: djgpp-workers/2003/12/29/16:48:28
Hello.
Kbwms AT aol DOT com wrote:
> In a message dated 12/23/2003 4:50:22 PM Eastern Standard Time,
> rich AT phekda DOT gotadsl DOT co DOT uk writes:
>
>> Why not just remove the definitions of is*f from <ieefp.h>?
>>
>> >If the changes persist into DJGPP v2.04, I will submit correcting
>> >patches that restore the code. The functions to be "reverted" are
>> >listed in the forwarded email and below:
>> [snip]
>>
>> I can revert the patches I applied, once my question about <ieefp.h>
>> above is answered.
>
>
>
> Unfortunately, the macros suffer from what is popularly known as
> "legacy." We do not know who has been using those atrocities. The fact
> that the macros enable improper aliasing won't deter people who do not
> know better. My suggestion is to let the macros stand in ieeefp.h and
> avoid their use via the patch to fdlibml.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>.
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?
Thanks, bye, Rich =]
--
Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ]
"You can't evaluate a man by logic alone."
-- McCoy, "I, Mudd", Star Trek
- Raw text -