Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!jarthur!uci-ics!ucla-cs!twinsun!eggert
From: eggert@twinsun.com (Paul Eggert)
Newsgroups: comp.std.c
Subject: Re: Questions about NCEG
Message-ID: <1990Jun5.232155.22743@twinsun.com>
Date: 5 Jun 90 23:21:55 GMT
References: <8924@celit.fps.com> <1990Jun5.024808.14003@twinsun.com> <8949@celit.fps.com>
Sender: usenet@twinsun.com
Organization: Twin Sun, Inc
Lines: 33

Patricia Shanahan suggests trapping unordered comparison, combined with new
syntax like:

	if (x>y) /* code for x > y case */;
	else /* code for x <= y case */;
	unordered /* give up gracefully, without taking a trap. */;

There is no need to change C's syntax.  For example, one could write:

	if (unordered(x,y)) /* give up gracefully, without taking a trap. */;
	else if (x>y) /* code for x > y case */;
	else /* code for x <= y case */;

using the unordered() predicate suggested in IEEE 754's appendix.
Unfortunately, the appendix is not binding.  For example, Sun does not support
unordered(x,y), and on Suns one must write something like isnan(x)||isnan(y)
instead.  NCEG should standardize this area.

Shanahan also asks:

	... if any of you have a copy of IEEE 754 handy, which does it say?
	Treat unordered comparisons as traps, unless a special operator is used
	to handle them, or treat all unordered relations as false.

IEEE 754 says comparisons involving < or > signal the invalid operation
exception if either operand is not a number.  The default response to such an
exception ``shall be to proceed without a trap'', and yield false.  A user
``should be able to request a trap'' on such an exception.

I urge those who seriously build or use ANSI/IEEE Std 754-1985 implementations
to get and read a copy of the standard, if only to learn what they dislike
about it!  Aside from boilerplate, it is only eleven pages long, and it is easy
to read.