std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/09/85)
In the interests of compatibility with X3J11, most of these sections 6. Nonlocal Jumps (setjmp, longjmp) 10. C Language Library 11. Sorting and Searching (bsearch, qsort) 13. Errors and Diagnostics (perror) are no longer in the P1003.D4 draft. Instead, there will be some sort of reference to the X3J11 standard, the exact form of which will be decided at the Steering Committee meeting in Dallas in early November. Section 2.6, C Language Definitions, may be further revised, as well. There are several exceptions. The following remain with P1003: ctermid, cuserid, fileno, fdopen, mktemp, ttyname, and isatty. Thus all stream (FILE *) returning functions go to X3J11, while all file descriptor-returning functions remain with P1003. These are no longer in either draft standard: swab, ecvt, fcvt, and gcvt. I think bsearch and qsort are still in the X3J11 draft, but they are removed from the P1003 draft. The conversion functions _toupper, _tolower, toascii, and isascii are handled by X3J11 (in slightly different forms), but no longer by P1003. These are in both the P1003 and the X3J11 drafts: getenv, exit, kill, signal, and time. The currently intended way of handling kill and signal is that X3J11 will define the syntax and a certain small subset of legitimate arguments and behavior, while P1003 will add more signals and more behaviors. Exit (section 3.2.2) is a controversial topic, as both committees would like to have complete control over it. The points of contention are that the X3J11 definition refers to streams, which are no (almost) no longer referenced by P1003, and also the onexit function. P1003 has defined _exit (just like the real _exit which appears in most known UNIXes) and has recommended that X3J11 drop onexit from their exit. I frankly can't remember whether P1003 has actually dropped exit completely in favor of _exit. Also, everyone is aware that some of the P1003 Numerical Limits of section 2.7 (particularly the floating point ones) conflict with those of X3J11. This is being worked on by the X3J11 liaison committee, and will probably take a more definite form in Dallas. Section 2.7 is in fact that of the previous draft (D3), due to a clerical error which misplaced the changes made to it at the Portland meeting. The real limit definitions will be replaced and further revised in the next draft. The definition of errno (section 2.3, Error Numbers) is still in both draft standards. The issue of the proper wording of what happens to the value of errno when a function succeeds will likely come up again in Dallas, once we know whether X3J11 has again modified their wording. Once again, remember that these are only my opinions, and not those of the P1003 committee, IEEE, or anyone else. Volume-Number: Volume 2, Number 14