std-unix@ut-sally.UUCP (Moderator, John Quarterman) (12/13/85)
Date: Thu, 12 Dec 85 10:09:56 EST From: Arnold Robbins <arnold%gatech.csnet@CSNET-RELAY.ARPA> Chapter 10: Data Interchange Format John Gilmore (l5!gnu) has already done a better job of commenting on this than I could. I will note two spelling errors: The standard does not define the user interface to this program and notes that the format-interpreting and format-translating utilities need not be the same, thougt an implementor may chose to make them so. "Thought" should be "though" and "chose" should be "choose" =========================== Appendix A: Trial Use Areas of Comment A.5 Media Formats I don't think this really needs to be specified, but if the standard is going to, then for 9 track 1/2 in. tape, the most portable format is 1600 BPI, "blocked" 10, i.e. 512 byte blocks * 10 blocks == 5K block tape records. This format tar tape is readable on basically any machine, including the ATT 3B20s which have exceedingly brain-damaged tape controllers (can't read any more than 6K off the raw tape device). ----------- A.7.2 Error Number Validity I like the proposed change for the third sentence of errno 2.4. This solves the problems described. =========================== Appendix C. Device Control and Terminal Characteristics. ... listed here with a request that it be review, ... Should be "reviewed". --------------------- C.1 I/octl/Iocntl/Termcnt Overview However, the definition of the terms would force low level concepts to be included a supposedly high level interface definition. "to be included in a supposedly.." --------------------- C.3.3 Problems (with current ioctl) This section makes a big deal out of binary compatibility, but the standard explicitly states in Chapter 1, Scope, that binary compatibility is not an issue. If so, most of this section loses its validity. --------------------- C.3.5 SVID Compatibility It seems that the people who came up w/this don't know their C too well either. Their definition #define ioctl(a,b,c) iocntl(a,b,c,sizeof(c)) should be #define ioctl(a,b,c) iocntl(a,b,c,sizeof(*(c))) ---------------------- C.7.2. Description (of <termios.h> Discusses the _getty_ program actually opening the terminal devices and then passing them on to _init_ and regular programs. Seems to me that neither getty nor init are described anywhere else. For the real standard, this would have to be cleaned up. ---------------------- C.7.2.6 Local Modes and Line Discipline ... These functions may be disabled individually by changing the value of the control character to an unlikely or meaningless value (e.g. 0377). This is a nit, but it should be '\377', not 0377. When ICANON is set, the following echo functions are possible. Two fucntions are possible: those dealing.... Should be: When ICANON is set, the following two echo functions are possible: those dealing.... ======================== Appendix I. Comparison to SVID Document. I.2.12 Readdir struct dirent int_t d_ino Should be "ino_t" instead of "int_t". ========================= Appendix J. Proposed Definitions J.2 General Terms Directory Entry A directory entry contains two items: a string whch is the filename and a file serial number. Should be something more like: Directory Entry A directory entry contains at least two items: a string whch is the filename and a file serial number. Other, implementation- dependant items may also be included in the directory entry. ======================== Appendix K. Contiguous Files K.5.1.2 Description (of allocf()) O_CREAT .... The ``save text image after execution bit'' of the mode is cleared. See _chmod()_. The rest of the standard doesn't say anything about sticky bits. K.5.1.4 Errors [ETXTBSY] The file is a pure procedure (shared text) file that is being executed and _oflag_ is write or read/write. This isn't in the rest of the standard. Volume-Number: Volume 4, Number 15