How is NCEG going to resolve this conflict... <9009120027.AA10058avalidgh.com>

[Donn Terry]

I normally just watch this group, however in this case I think I can
usefully add something.

1) I feel that it has now proven itself a requirement that X3J11 (and
   probably most of the rest of X3J*) must be required to "coordinate"
   with IEEE 754 so situations like this don't happen again.  (The
   purpose of coordination is so that standards don't end up in 
   head-to-head conflict like this.)  I'm going to go further: unless
   someone convinces me otherwise in a few days that it's a bad idea,
   I'm going to forward this discussion to "the right people" so that
   it is recognized as an issue to be addressed.  (This could be read
   as a "threat"; I really don't want it to be read that way, but I don't
   see an easy way to rewrite it so it can't be misread that way, so I'll
   just add this parenthetical remark. I believe that at least some of
   the problems that NCEG is finding in C is lack of such coordination.  I
   don't have access to the Project Authorization (NWI, whatever X3 calls
   it) that would tell me if coordination was required with 754, but it's
   obvious that it didn't happen properly, and I believe that future work
   should take that error into account.)

2) So-far, at least, POSIX doesn't say anything about the math functions.
   However, I have written up a paper where I've proposed to tighten things
   up a bit so at least the Standard C vs. SVID war can be resolved by a 
   formal standard.  POSIX will have a vehicle that will be able to carry
   such a statement.  The "short" gist of it is that there are 3 types
   of math defined: IEEE, "something like IEEE (NaNs and INFs present,
   but not everything else", and "classical (no NaNs and INFs)".  The
   application can tell which of the 3 it has at compile time, and error/
   exception actions from functions are defined for all 3.  In addition,
   I/O for INFs and NaNs is defined in the POSIX Locale.  (It can't be
   in the C locale because if you read C closely enough it requires that
   "NaN" and "INF" (and friends) be treated as errors (because they aren't
   "numbers" in the sense of signs, digits, and E's).  The paper has
   been met with some resistance, and mostly yawns, so I havn't pushed it.
   NCEG has received copies, but no-one has responded.

   If there is a useful statement that POSIX can make that would not 
   conflict with NCEG's work and which would address some of these immediate
   problems, it can be considered for POSIX.  The next "train" leaves
   probably in the spring, and arrives a bit more than a year from now,
   I think.  This appears to be much sooner than NCEG could do anything.

   I wouldn't want to go much beyond what I've discussed above, however,
   as even what I discuss is at the very edge of scope for POSIX.


Donn Terry
(Who happens to be chair of IEEE P1003.1, but who is speaking for himself
in this letter.)