std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/09/85)
This is the first of a series of articles about changes which were made to the P1003 D4 proposed draft standard at the D.C. meeting. This one contains a few general comments. All these comments are my opinion, and not the official position of IEEE, P1003, or anyone else. While I think I understand the things I'm writing about here, I've only been to two committee meetings. I trust that other, more experienced members will correct me if I stray too far from the consensus. Many people have the impression that the P1003 standard will be almost exclusively based on System V. This is not really true. The draft standard is probably closer to System V than to any other variant of UNIX, and the System V Interface Description is a constant reference at committee meetings. However, committee members often express concern about not outlawing features of hosted systems (emulations on top of other operating systems), networked systems, or distributed systems. (The standard does not explicitly address most of these issues, it just carefully does not make them impossible or hard to do.) Also, many of the committee members run non-System V-based software on their own systems at work. 4.2BSD features, in particular, are frequently mentioned. Thus, while some System V-specific features like FIFOs appear in the standard, the mechanisms provided for reading directories are the 4.2BSD opendir/readdir/closedir functions, and the data interchange format is tar, not cpio. Another major concern of the P1003 committee is compatibility with the X3J11 C standard. This led to major modifications to P1003.D4. An issue which has not been addressed thus far to any great extent is internationalization. There is no mention of character sets other than ASCII, for instance. And another issue which is explicitly not addressed is binary compatibility: the standard is intended to facilitate the writing of programs whose *source* may then be moved from one conforming implementation to another with minimal changes. While the P1003 committee wishes to produce a standard which is inclusive enough to be of use, it is necessary to start with a small trial use standard and include other issues in later drafts. In the specific comments on P1003 D4, note that I identify things by draft number and section number, not page number. This is necessary, due to the many printed forms of the draft. Please do the same in any comments you submit to the committee or to the newsgroup. Volume-Number: Volume 2, Number 13
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/09/85)
This article mentions some changes to the P1003.D4 draft by section, sometimes with discussion of the motivation for the changes. There were far too many changes to record them all, and I do not have the minutes which have the details anyway. Thus I am trying here merely to mention changes which strongly affect the reader of P1003.D4, in hopes of reducing duplicate effort. Section 2.2, General Terms, has been expanded to include many previously missing definitions. There was a proposal to change the format to be more tutorial, with definitions of specific terms embedded in paragraphs discussing related concepts (in fact, the writeup in that form was considered to be the text of that section for D4 instead of what appears in the current copy, which is older). The consensus was that, while there is certainly a need for such tutorial material, a standard is a reference, not a place to learn the operating system. The result is the same general form as that of P1003.D4, though somewhat more detailed. Much attention has been paid to error codes throughout the document. Many of the definitions in 2.3, Error Numbers, have been revised. The spurious last sentence about structure elements in section 2.4 has been deleted. Most places where the numeric values of symbolic constants were given, such as section 2.8, Symbolic Constants, the numeric values have been removed, and the form of the display has been changed from C preprocessor definitions to a table. I believe there is an intention to give the numeric values in appendices as examples of what they historically have been. The main exception is section 14. Data Interchange Format, as the values of the bytes on the tape or other interchange medium must be defined. In section 4.2, User Identification, it was decided that there was no need for three methods of getting the user's login name (cuserid, getlogin, and getlogname). Getlogname was removed, and the writeups of the other two were redone to emphasize when it was appropriate to use each. Note that though the logname function was removed, the LOGNAME environment variable was not. These changes are different from what is in the SVID or X/OPEN documents. Ustat, and its containing section 7.9.1, File System Statistics, no longer exist. The reasoning was that only a very few programs used it (df and ed) and it does not generalize easily to networked file systems. Df is not defined by the standard, and the use of ustat in ed is not necessary and not sufficient. Also, ustat required the definition of a "mounted file system" which was otherwise not in the standard (as mount and umount are not). In section 8.3, Pipes, much work was put into producing a description which permitted most known existing implementations while retaining enough specificity to be useful. There are a few areas which will affect existing implementations, but this is more because there already were conflicting implementations, not that P1003 wishes to legislate one version as the better one. A table will appear in an appendix showing what happens with various attempts at writing with O_NDELAY on or off, and with differing buffer sizes. The Version 8 manual was an inspiration for some of the wording. In section 8.6, Input and Output, a proposal to change the nbyte arguments of read and write from type int to unsigned failed to pass the committee, as has apparently happened many times before. Verbiage was added to the Errors subsections to clarify what may happen if a negative nbyte argument is passed. In section 8.7.3, File Record Locking, the last vestiges of references to enforcement mode were removed. There were only two known implementations of enforcement mode, and the representatives of both companies (AT&T and HP) said they had done it only because the /usr/group standard had included it, and they would be happy to have it removed. Section 9.1.1, Termios, does not appear in the copy of the draft which is currently available, but was supplied to the committee as a separate document which I believe was considered to be part of P1003.D4. The subcommittee which considered it at the meeting recommended removing it from the draft standard altogether. The reasons for this were various, including that the wording was too stringent in places (it would apparently require an X.25 or TCP/IP/RS232C connection to act like an ordinary terminal port) and too vague in others (it was not clear what a line discipline was). Also, there was no provision for speeds other than the traditional ones up to 19200 baud, only one direction of XON/XOFF protocol was supported, etc. In the full committee, several members objected to the removal of the termio section on the grounds that a) many of the objections to the section were internationalization issues, and the committee had otherwise explicitly avoided addressing such issues, and b) the draft standard really needed a termio section, as it would risk being voted down by the balloting committee if it lacked one. It was speculated that the /usr/group standard would have had more influence if it had included a similar section. The resolution was to put the existing termio section in an appendix, while letting section 9.1.1 refer to the appendix, saying something to the effect that the committee did intend to have a section similar to the one currently in the appendix, but possibly not until after trial use. This prohibits anyone from specifying compliance to the current termio section, while making the intention to include one clear. In section 12. Passwords, there are no longer any references to text files for the /etc/passwd or /etc/group information. Only the getpwent and getgrent functions are defined: the internal storage format is not defined. 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 15