| PLEX86 | ||
Where should the type information be 219
comp.arch removed.
Whereas 7.6 #2 says that they may be produced. While I agree that any sane reader would buttume that is the case only if Annex F is not in force, unfortunately insane readings of the standard are sometimes necessary to make it consistent or implementable. There is also the first paragraph in F.9: facilities that are particularly suited for IEC 60559 implementations. That could be read to imply that the rest of F.9 is advisory. But also consider: #10 Whether the functions honor the rounding direction mode is implementation-defined. Is it allowed to say "No, they don't. All operations will force a 1 into the last bit (an old, old method of rounding)." If not, why not? See above :-) Also see below :-) Most vendors that I have dealt with disagree. Upon reading those sections of the standard many times, forward and backward, I am unable to decide if they are wrong, merely perverse, or right. This was with regard to 3.0+2.0. 6.6 #2 says that may be done at translation time. Also 6.6 says: #10 An implementation may accept other forms of constant expressions. I can find nothing in the standard that forbids an implementation from optimising any expression by doing it at translation time, if it feels like it. Nor any explicit wording that requires IEEE 754 arithmetic to be used at translation time even if STDCIEC559 is set. Where should the type information be 220 Try the specifications of signal handling and I-O. Is longjmp from catching a SIGFPE defined behaviour or not? The wording implies... Where should the type information be 222 and I've managed to write another sentence with blurred meaning. :-) Exactly. And the reason a ** was invented to translate to exponentiation... Regards, Nick Maclaren.
|
||||
Where should the type information be 220 Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||