Standards Update, IEEE 1003.1: System services interface
Jeffrey S. Haemer
jsh at usenix.org
Sun Dec 3 06:24:11 AEST 1989
From: Jeffrey S. Haemer <jsh at usenix.org>
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 <md at inset.co.uk> 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 <jason at hpcndr.cnd.hp.com>, 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
More information about the Comp.std.unix
mailing list