Some trivia questions.

[queueing-rmail]

Excuse me for bustin' in on the interesting (and spirited) discussion on
LIA, but I have a few mundane questions to ask, and quite frankly, I
couldn't think of a better forum (than the nceg mailing list) to ask
them in.

I'm hacking a bit on the GNU C library, and I'm just now trying to get
it to do something reasonable when confronted with strange arguments
for the acos() function.  The problem is that I don't know what's
"reasonable".

For example, what should be the effect(s) and/or results of the following
calls:

		acos (SNaN)
		acos (QNaN)
		acos (1.1)
		acos (-1.1)

The ANSI standard, in section 4.5.1, says that for all the math functions:

	"Each function shall execute as if it were a single operation,
	without generating any externally visible exceptions."

My gut feeling is that this statement conflicts which what I understand
to be the general intent of the IEEE 754 floating-point standard.  It
sure seems to me that if you have IEEE floating-point "invalid operation"
traps enabled, that you ought properly to expect that you'll get something
like a SIGFPE, at least for the call `acos (SNaN)' and perhaps also for
the call `acos (QNaN)'.  But if if I'm reading the standard correctly,
then it appears that a library implementor is actually PROHIBITED from
bringing these kinds of invalid operations to the user's attention (in
no uncertain terms, e.g. by raising a SIGFPE).

So am I reading the standard right?  Are library implementors really
prohibited from raising a SIGFPE in the math furnctions for any reason?

If so, is the NCEG considering making a proposal to change this requirement
of the ANSI C standard?  As a sometimes-end-user myself, I'd like to at
least be given the opportunity to be *told* (via a signal) that I've
screwed up somewhere when calling a math function.

Separately, I'd like to know if there is any consensus among implementors
regarding the effects and results of the calls:

		acos (1.1)
		acos (-1.1)

All the standard says is that the library sets errno to EDOM and then
returns an implementation-defined value.

Does anybody's library implementation try to raise a SIGFPE for these
calls (if IEEE traps are enabled)?  Does anyone try to return SNaNs
for these calls?  How about returning QNaNs?  How about returning
Infinities?  How about returning HUGE_VAL?  How about returning 0.0?
How about returning anyone of those possibilities with the sign set
the same as the original (input) argument?

I'd really like to know what the Right Thing to do for these calls is.


// Ron ("Loose Cannon") Guilmette
// uucp: ...uunet!lupine!segfault!rfg
// New new motto:  Quality control is a state of mind.
//   misc.forsale.computers ad, circa 2007:
//       Used Cray wrist watch for sale; 25 bucks or best offer.