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 that it is, but it is often unimplementable. Streams are required to preserve tabs and lines of 254 characters, and stderr is required to be not fully buffered. Those are unimplementable if the (necessarily preattached) file does not support those, as is clearing a hard I-O error or EOF.
Where should the type information be 221
Nick Maclaren Which is how it is supposed to be read. Please provide an example of that claim. Not when F.1 has: "An implementation that defines STDCIEC559 shall conform to...
For examples of inconsistency, take a look at my Objects diatribe, especially the sections on effective type and how big an array is. I am unable to find a consistent reading, and every person who has claimed that there is (a) has provided a different one and (b) has not been fully consistent. It really DOES matter for parallelism.
A more fundamental one is the definition of undefined behaviour. 4 #2 states clearly that reliance on ANY unspecified detail is EXACTLY the same as a major breach of the standard. This means that pretty well all floating-point use is undefined behaviour unless both STDCIEC559 and FENVACCESS are on. And so is all I-O :-(
Why should the generic override the specific in this case, when this annex is overriding the main body of the standard?
I can butture you that I have had DOZENS of debates with MANY vendors, that have come down to which sentence of the standard overrides which other. From the reflector, I often know what was intended, but the vendors' staff aren't on that. I have given up reporting breaches of standard in C compilers - it isn't worth the effort.
Oh, I agree that is the intent.
As described above - they use a different override order for the various parts of the standard. YOU know what was intended - I have a clue from the reflector (and the NCEG equivalent) - THEY have merely the standard to go by.
Regards, Nick Maclaren.