Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!uunet!longway!std-unix From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.1: System services interface Message-ID: <454@longway.TIC.COM> Date: 2 Dec 89 19:24:11 GMT Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee Lines: 280 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: Jeffrey S. Haemer An Update on UNIX* and C Standards Activities December 1989 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.1: System services interface Update Mark Doran reports on the October 16-20, 1989 meeting in Brussels, Belgium: P1003.1 is now a full-use standard, so interest in attending the working group has wained somewhat. Attendance didn't get above fifteen or so all week and was nearer half a dozen most of the time. Even so, this was a bit low by comparison with recent meetings. So where was everyone? [Editor's note -- Notice that this is larger than the attendance at typical meetings of, for example, dot nine. "Low attendance" is relative. Author's additional note -- And that's the frightening thing; standards being established by as few as half a dozen _i_n_d_i_v_i_d_u_a_l_s. This cannot be representative or balanced. Scary stuff, "...as we take you on a journey, into the Standards Zone..."] We were all lead to believe that meeting in Brussels was going to further the cause of international participation in the POSIX process. Several people I would normally expect to see, didn't show; Europe must be too far from home for a lot of the regulars. Unfortunately, neither did I see more than two or three European types (whom I would not normally expect to see at POSIX) all week either. Oh well, I'm sure it was a good idea really... So what did those that showed get up to? Well, in chronological order: 1. ISO 9945 Status and Document Format 2. P1003.1a Balloting 3. Transparent File Access __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. December 1989 Standards Update IEEE 1003.1: System services interface - 2 - 4. Language-Independent Specification 5. Messaging 6. P1003.1b In detail: 1. ISO 9945 [Editor's note -- ISO 9945 is, roughly, the ISO standard engendered by and corresponding to the POSIX work.] It looks like 9945 is going to be split up into three major pieces, the first of which is founded upon the IEEE P1003.1-1988 standard. This piece is likely to include all the other system interfaces as well (notably, the real time stuff from P1003.4). The other two pieces will be based around utilities and system administration. The basic IS9945-1:1989 will be just the same as the regular, ugly-green, dot-one book -- well almost. ISO has yet another documentation format and the book will have to be squeezed to fit it. And before you ask, this one doesn't allow line numbers either. We are assured that making the changes is not a major problem, but the working group has still requested a new disclaimer telling readers that all mistakes are the fault of ISO! 2. P1003.1a [Editor's note -- This document (supplement A) is supposed to contain clarifications of and corrections to P1003.1-1988, but no substantive changes.] The meeting discussed resolution issues from the first ballot. Highlights included: - the decision to withdraw the cuserid() interface; its loss will not be sadly mourned since one can use other interfaces to do the same job better. - the addition of a new type name ssize_t (yes, two s's) to represent signed size_t values; this has all sorts of uses -- for example, in the prototype for read(). Currently, the parameter specifying the number of bytes to be read() is given as a size_t, but read() has been specified to December 1989 Standards Update IEEE 1003.1: System services interface - 3 - return an int, which this may not be large enough to hold a size_t character count. Moreover, read() may return -1 for failure, or the number of characters read if the call was successful. The recirculation ballot happened between November 10-20; if you care but didn't know that already, it doesn't matter because you (and many others, I suspect) have missed your chance. This all seems a bit fast but it does mean that P1003.1a will hit an ISO, six-month, letter-ballot window; standards must progress you know... 3. Transparent File Access Isn't this a P1003.8 problem? Yes, but the chair of the TFA committee came to talk about TFA semantics as they relate to P1003.1. The crux of the matter is that the TFA folks (all six of them...) seem to have decided that standardizing NFS will do nicely for TFA. Their chair wonders whether the rest of the world (or, more accurately, the balloting group for a TFA standard) will agree. The answer from the dot one folks appears to be definitely not (thank goodness)! There appear to be several arguments against NFS as the TFA standard from dot one. These include: - It is impossible to maintain full dot one semantics over a network using NFS. Consider the last-close semantics, for example, which can only be preserved over a network using a connection-oriented protocol, which NFS is not. - Transparent File Access should be _t_r_a_n_s_p_a_r_e_n_t; NFS isn't. It is possible for operations that are logically sound to fail because of network timeouts. - NFS is a _d_e _f_a_c_t_o standard; why should it get an official rubber stamp? This appears to be a hot topic that many groups may have an interest in, so there will be an "out-of-hours" meeting on TFA at the New Orleans POSIX -- If you care at all, I suggest you try to show up... [Editor's note -- If you do care but can't go to New Orleans, we suggest either writing directly to the TFA chair, Jason Zions , or posting your opinions to comp.std.unix.] December 1989 Standards Update IEEE 1003.1: System services interface - 4 - 4. Language-Independent Specification It seems to have been decided that POSIX API standards should be written in a language-independent form, i.e. not expressed in C-language constructs. My initial reaction was one of horror, but then someone quietly pointed out to me that C is not the only programming language in the known universe. This I have to concede, along with the idea that bindings to POSIX APIs in other languages may not be such a bad idea after all. Indeed work is well underway to produce FORTRAN and ADA bindings. But now it seems we have to express POSIX in a language- independent way. "Why?" I ask... Well, this means that when you come to write the next set of actual language bindings, the semantics you'll need to implement won't be clouded with language-dependent stuff; the idea is that you won't have to understand C in all its "glory" to write new language bindings. So what will the language-independent specifications look like? Will I be able to understand those? The current proposal doesn't look like anything I recognize at all. Yes, that's right, we have to learn a whole NEW language (sigh). Why not use a more formal specification language that a few people know? (Like ASN.1 for example, which P1003.7 has decided to use.) Better yet, why not use constrained English -- lots of people can read that... Come to think of it, since the FORTRAN and ADA bindings folks have managed without the aid of language-independent specifications, why can't everyone else? Is there more to this than a glorified job creation scheme? ("Wanted: expert in POSIX 'language-independent' language...") If there is, do we have to invent a new wheel to get the job done? As you can tell, my opinion of this effort is somewhat jaundiced. Perhaps, you may say, I have missed the point. Maybe so; but if I have, I feel sure that some kind soul will be only too happy to correct me in "flaming" detail :-) 5. Messaging The UniForum internationalization (I18N) folks brought forward a proposal for a messaging facility to be included in P1003.1b. The working group decided that it needs some more work but will go into the next draft. [Editor's note -- The problem being solved here is that internationalized applications store all user-visible strings in external files, so that vendors and users can change the December 1989 Standards Update IEEE 1003.1: System services interface - 5 - language of an application without recompiling it. The UniForum I18N group is proposing a standard format for those files.] 6. P1003.1b Work on production of the second supplement is still at a formative stage. Indeed, the group is still accepting formal proposals for functionality to add to the document. Where P1003.1a has been drawn up as a purely corrective instrument, P1003.1b may add new functionality. Among the interesting things currently included are these: - The messaging proposal described above. - A set of interfaces to provide symbolic links. The basic idea is that lstat(), readlink() and symlink() operate on the link, and all other interfaces operate on the linked-to file. Rationale will be added to explain that '..' is a unique directory, which is the parent directory in the same physical file system. This means that cd does not go back across symlinks to the directory you came from. This is the same as the semantics on my Sun. For example: (sunset) 33 % pwd /usr/spare/ins.MC68020/md/train (sunset) 34 % ls -ld ./MR_C++ lrwxrwxrwx 1 root 32 Sep 30 1988 MR_C++ -> /usr/sunset/md/c++/trainset/c++/ (sunset) 35 % cd MR_C++ (sunset) 36 % pwd /usr/sunset/md/c++/trainset/c++ (sunset) 37 % cd .. (sunset) 38 % pwd /usr/sunset/md/c++/trainset The rationale is meant to help keep readers' eyes on what's really written in the standard and help them avoid misinterpreting it along lines of their own potential misconceptions. - P1003.1b used to have two descriptions of Data Interchange formats. Now it has only one. The working group picked the one that remains because it more closely existing December 1989 Standards Update IEEE 1003.1: System services interface - 6 - standards in the area, in particular the surviving proposal refers to X3.27. December 1989 Standards Update IEEE 1003.1: System services interface Volume-Number: Volume 17, Number 82