IEEE_754 logic

Kurt Hornik
Thu, 21 Oct 1999 11:20:46 +0200 (CEST)

>>>>> Thomas Hoffmann writes:

>> >>>>> Peter Dalgaard BSA writes:  
>> > > Thomas Hoffmann <> writes:  
>> >> 3.  The C9x draft introduces
> the is*() functionality under the name of "classification MACROS".  If an 
>> >>implementation implements this standard, autoconf misses isnan() and isfinite().
>> >>

> The problem for me is, that if isnan and isfinite are the way C9x says
> (i.e.  are MACROS), then configure concludes "not there" (AC_FUNCS
> misses macros (intentionally)).

> From this it reasons "not IEEE 754".

> Then I get back to a native finite() in Arith.h, but IEEE 754 mode was
> switched off.

> So I see two topics:

> 1.  Maybe not to (only) check if isnan/isfinite are library functions,
> but also to check for working macros (I have not found a predefined
> macro in Autoconf for this).

> This seems of some importance to me, because it is not only an
> idiosyncracy of a singular system, but may become a more widespread
> problem if systems become C9x compliant someday.

This should be doable.  In fact, this is what the code in Arith.h does
for one case, sort of.  I don't think that there is a macro in autoconf
that checks whether FOO exists as a library function or is defined as a
preprocessor symbol for another library function.

(We used to have a similar problem with sigsetjmp, which e.g. under
GNU/Linux is a macro ... so code which later tests for HAVE_SIGSETJMP
would not do the right thing.  I ended up writing a test which uses

Question: does IEEE 754 require the `#include <math.h>'?  (And do all
implementations conform?)  Then we could use AC_EGREP_HEADER tests for
finite and isfinite ...

> 2.  Introduce a more bulletproof check for IEEE 754.

> Is there possibly a computation we can carry out and conclude from its
> result to IEEE 754?  I just have no idea.

(Don't think so.  Does anyone know?)

r-devel mailing list -- Read
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: