Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP Path: utzoo!watmath!clyde!cbosgd!ucbvax!ucdavis!lll-crg!mordor!ut-sally!std-unix From: std-unix@ut-sally.UUCP (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: P1003/D4 editorial comments Message-ID: <3431@ut-sally.UUCP> Date: Fri, 8-Nov-85 21:40:51 EST Article-I.D.: ut-sally.3431 Posted: Fri Nov 8 21:40:51 1985 Date-Received: Sun, 10-Nov-85 10:04:32 EST Organization: IEEE/P1003 Portable Operating System Environment Committee Lines: 62 Approved: jsq@ut-sally.UUCP Date: 06 Oct 85 20:21:37 +1000 (Sun) >From: Robert ElzSection 2.4 [ of Draft 4; Section 2.5 of Draft 5 -jsq ] terminates with a sentence that does not belong, there are no structures mentioned anywhere in this section. [ I previously reported that this had been fixed by removing the sentence. In fact the change Doug mentions below was done. -jsq ] [ This sentence was changed in Draft 5 to say that all TYPES defined in this file SHOULD have type names ending with _t. -Gwyn ] Several sections (eg: 3.3.2.6) indicate that longjmp is defined in the X3J11 C language standard. It is also defined in section 6. This seems to be one function that clearly belongs in the C standard, I would delete section 6 completely. (Currently it makes reference to "auto" and "register" "storage classes" none of which terms seem to be defined anywhere, or within the scope of this standard). Deleting section 6 would also get rid of the most objectionable (and unnecessary) sentence... However longjmp shall never cause setjmp to return a value of 0. At best a caution that some implementations may not allow setjmp to return 0 when called from longjmp would be called for. [ The offending section was removed for Draft 5. -Gwyn ] [ In general, anything which is C and not UNIX has been removed from P1003 and replaced with pointers to X3J11. I posted a detailed synopsis of these sorts of changes a couple of months ago. -jsq ] Section 4.5.2 seems to be largely repeated in section 4.5.3.2. The former should probably simply be deleted. [ Draft 5 has instead uniformly defined data structures like this at the beginning of subsections and omitted them from the individual routines. It also has put #defined constants into tabular form instead of mock C code. -Gwyn ] Apart from minor glitches like these, I must complement the editors, it is obvious that much thought has gone into wording this draft in a manner that will result in just the results desired. Congratulations. [ Draft 5 appears at first reading to be substantially better organized than Draft 4 and also technically improved. I have only a few relatively minor quibbles with it as it now stands, apart from the absence of a termio specification. -Gwyn ] [ Termio was a topic of much discussion at the D.C. meeting. The former draft currently appears in an Appendix, with a pointer to it from the text of the draft, saying in effect that P1003 intends to have such a section in the final draft, but it was not possible to agree on that particular section draft in time for Trial Use. -jsq ] Robert Elz seismo!munnari!kre kre%munnari.oz@seismo.css.gov Volume-Number: Volume 3, Number 11