home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0073.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  11.1 KB
  1. From: Jeffrey S. Haemer <jsh@usenix.org>
  2.  
  3.  
  4.  
  5.             An Update on UNIX* and C Standards Activities
  6.  
  7.                             December 1989
  8.  
  9.                  USENIX Standards Watchdog Committee
  10.  
  11.                    Jeffrey S. Haemer, Report Editor
  12.  
  13. IEEE 1003.1: System services interface Update
  14.  
  15. Mark Doran <md@inset.co.uk> reports on the October 16-20, 1989 meeting
  16. in Brussels, Belgium:
  17.  
  18. P1003.1 is now a full-use standard, so interest in attending the
  19. working group has wained somewhat.  Attendance didn't get above
  20. fifteen or so all week and was nearer half a dozen most of the time.
  21. Even so, this was a bit low by comparison with recent meetings.  So
  22. where was everyone?
  23.  
  24. [Editor's note -- Notice that this is larger than the attendance at
  25. typical meetings of, for example, dot nine.  "Low attendance" is
  26. relative.
  27. Author's additional note -- And that's the frightening thing;
  28. standards being established by as few as half a dozen _i_n_d_i_v_i_d_u_a_l_s.
  29. This cannot be representative or balanced.  Scary stuff, "...as we
  30. take you on a journey, into the Standards Zone..."]
  31.  
  32. We were all lead to believe that meeting in Brussels was going to
  33. further the cause of international participation in the POSIX process.
  34. Several people I would normally expect to see, didn't show; Europe
  35. must be too far from home for a lot of the regulars.  Unfortunately,
  36. neither did I see more than two or three European types (whom I would
  37. not normally expect to see at POSIX) all week either.  Oh well, I'm
  38. sure it was a good idea really...
  39.  
  40. So what did those that showed get up to?  Well, in chronological
  41. order:
  42.  
  43.   1.  ISO 9945 Status and Document Format
  44.  
  45.   2.  P1003.1a Balloting
  46.  
  47.   3.  Transparent File Access
  48.  
  49. __________
  50.  
  51.   * UNIX is a registered trademark of AT&T in the U.S. and other
  52.     countries.
  53.  
  54. December 1989 Standards Update  IEEE 1003.1: System services interface
  55.  
  56.  
  57.                                 - 2 -
  58.  
  59.   4.  Language-Independent Specification
  60.  
  61.   5.  Messaging
  62.  
  63.   6.  P1003.1b
  64.  
  65. In detail:
  66.  
  67.   1.  ISO 9945
  68.  
  69.       [Editor's note -- ISO 9945 is, roughly, the ISO standard
  70.       engendered by and corresponding to the POSIX work.]
  71.  
  72.       It looks like 9945 is going to be split up into three major
  73.       pieces, the first of which is founded upon the IEEE P1003.1-1988
  74.       standard.  This piece is likely to include all the other system
  75.       interfaces as well (notably, the real time stuff from P1003.4).
  76.       The other two pieces will be based around utilities and system
  77.       administration.
  78.  
  79.       The basic IS9945-1:1989 will be just the same as the regular,
  80.       ugly-green, dot-one book -- well almost.  ISO has yet another
  81.       documentation format and the book will have to be squeezed to
  82.       fit it.  And before you ask, this one doesn't allow line numbers
  83.       either.  We are assured that making the changes is not a major
  84.       problem, but the working group has still requested a new
  85.       disclaimer telling readers that all mistakes are the fault of
  86.       ISO!
  87.  
  88.   2.  P1003.1a
  89.  
  90.       [Editor's note -- This document (supplement A) is supposed to
  91.       contain clarifications of and corrections to P1003.1-1988, but
  92.       no substantive changes.]
  93.  
  94.       The meeting discussed resolution issues from the first ballot.
  95.  
  96.       Highlights included:
  97.  
  98.          - the decision to withdraw the cuserid() interface; its loss
  99.            will not be sadly mourned since one can use other
  100.            interfaces to do the same job better.
  101.  
  102.          - the addition of a new type name ssize_t (yes, two s's) to
  103.            represent signed size_t values; this has all sorts of uses
  104.            -- for example, in the prototype for read().  Currently,
  105.            the parameter specifying the number of bytes to be read()
  106.            is given as a size_t, but read() has been specified to
  107.  
  108. December 1989 Standards Update  IEEE 1003.1: System services interface
  109.  
  110.  
  111.                                 - 3 -
  112.  
  113.            return an int, which this may not be large enough to hold a
  114.            size_t character count.  Moreover, read() may return -1 for
  115.            failure, or the number of characters read if the call was
  116.            successful.
  117.  
  118.       The recirculation ballot happened between November 10-20; if you
  119.       care but didn't know that already, it doesn't matter because you
  120.       (and many others, I suspect) have missed your chance.  This all
  121.       seems a bit fast but it does mean that P1003.1a will hit an ISO,
  122.       six-month, letter-ballot window; standards must progress you
  123.       know...
  124.  
  125.   3.  Transparent File Access
  126.  
  127.       Isn't this a P1003.8 problem?  Yes, but the chair of the TFA
  128.       committee came to talk about TFA semantics as they relate to
  129.       P1003.1.
  130.  
  131.       The crux of the matter is that the TFA folks (all six of
  132.       them...) seem to have decided that standardizing NFS will do
  133.       nicely for TFA.  Their chair wonders whether the rest of the
  134.       world (or, more accurately, the balloting group for a TFA
  135.       standard) will agree.
  136.  
  137.       The answer from the dot one folks appears to be definitely not
  138.       (thank goodness)!  There appear to be several arguments against
  139.       NFS as the TFA standard from dot one.  These include:
  140.  
  141.          - It is impossible to maintain full dot one semantics over a
  142.            network using NFS.  Consider the last-close semantics, for
  143.            example, which can only be preserved over a network using a
  144.            connection-oriented protocol, which NFS is not.
  145.  
  146.          - Transparent File Access should be _t_r_a_n_s_p_a_r_e_n_t; NFS isn't.
  147.            It is possible for operations that are logically sound to
  148.            fail because of network timeouts.
  149.  
  150.          - NFS is a _d_e _f_a_c_t_o standard; why should it get an official
  151.            rubber stamp?
  152.  
  153.       This appears to be a hot topic that many groups may have an
  154.       interest in, so there will be an "out-of-hours" meeting on TFA
  155.       at the New Orleans POSIX -- If you care at all, I suggest you
  156.       try to show up...  [Editor's note -- If you do care but can't go
  157.       to New Orleans, we suggest either writing directly to the TFA
  158.       chair, Jason Zions <jason@hpcndr.cnd.hp.com>, or posting your
  159.       opinions to comp.std.unix.]
  160.  
  161. December 1989 Standards Update  IEEE 1003.1: System services interface
  162.  
  163.  
  164.                                 - 4 -
  165.  
  166.   4.  Language-Independent Specification
  167.  
  168.       It seems to have been decided that POSIX API standards should be
  169.       written in a language-independent form, i.e. not expressed in
  170.       C-language constructs.
  171.  
  172.       My initial reaction was one of horror, but then someone quietly
  173.       pointed out to me that C is not the only programming language in
  174.       the known universe.  This I have to concede, along with the idea
  175.       that bindings to POSIX APIs in other languages may not be such a
  176.       bad idea after all.  Indeed work is well underway to produce
  177.       FORTRAN and ADA bindings.
  178.  
  179.       But now it seems we have to express POSIX in a language-
  180.       independent way.  "Why?" I ask...  Well, this means that when
  181.       you come to write the next set of actual language bindings, the
  182.       semantics you'll need to implement won't be clouded with
  183.       language-dependent stuff; the idea is that you won't have to
  184.       understand C in all its "glory" to write new language bindings.
  185.  
  186.       So what will the language-independent specifications look like?
  187.       Will I be able to understand those?  The current proposal
  188.       doesn't look like anything I recognize at all.  Yes, that's
  189.       right, we have to learn a whole NEW language (sigh).  Why not
  190.       use a more formal specification language that a few people know?
  191.       (Like ASN.1 for example, which P1003.7 has decided to use.)
  192.       Better yet, why not use constrained English -- lots of people
  193.       can read that...
  194.  
  195.       Come to think of it, since the FORTRAN and ADA bindings folks
  196.       have managed without the aid of language-independent
  197.       specifications, why can't everyone else?  Is there more to this
  198.       than a glorified job creation scheme?  ("Wanted: expert in POSIX
  199.       'language-independent' language...") If there is, do we have to
  200.       invent a new wheel to get the job done?
  201.  
  202.       As you can tell, my opinion of this effort is somewhat
  203.       jaundiced.  Perhaps, you may say, I have missed the point.
  204.       Maybe so; but if I have, I feel sure that some kind soul will be
  205.       only too happy to correct me in "flaming" detail :-)
  206.  
  207.   5.  Messaging
  208.  
  209.       The UniForum internationalization (I18N) folks brought forward a
  210.       proposal for a messaging facility to be included in P1003.1b.
  211.       The working group decided that it needs some more work but will
  212.       go into the next draft.
  213.  
  214.       [Editor's note -- The problem being solved here is that
  215.       internationalized applications store all user-visible strings in
  216.       external files, so that vendors and users can change the
  217.  
  218. December 1989 Standards Update  IEEE 1003.1: System services interface
  219.  
  220.  
  221.                                 - 5 -
  222.  
  223.       language of an application without recompiling it.  The UniForum
  224.       I18N group is proposing a standard format for those files.]
  225.  
  226.   6.  P1003.1b
  227.  
  228.       Work on production of the second supplement is still at a
  229.       formative stage.  Indeed, the group is still accepting formal
  230.       proposals for functionality to add to the document.  Where
  231.       P1003.1a has been drawn up as a purely corrective instrument,
  232.       P1003.1b may add new functionality.  Among the interesting
  233.       things currently included are these:
  234.  
  235.          - The messaging proposal described above.
  236.  
  237.          - A set of interfaces to provide symbolic links.  The basic
  238.            idea is that lstat(), readlink() and symlink() operate on
  239.            the link, and all other interfaces operate on the linked-to
  240.            file.
  241.  
  242.            Rationale will be added to explain that '..' is a unique
  243.            directory, which is the parent directory in the same
  244.            physical file system.  This means that cd does not go back
  245.            across symlinks to the directory you came from.
  246.  
  247.            This is the same as the semantics on my Sun.  For example:
  248.  
  249.            (sunset) 33 % pwd
  250.            /usr/spare/ins.MC68020/md/train
  251.            (sunset) 34 % ls -ld ./MR_C++
  252.            lrwxrwxrwx  1 root  32 Sep 30  1988 MR_C++ -> /usr/sunset/md/c++/trainset/c++/
  253.            (sunset) 35 % cd MR_C++
  254.            (sunset) 36 % pwd
  255.            /usr/sunset/md/c++/trainset/c++
  256.            (sunset) 37 % cd ..
  257.            (sunset) 38 % pwd
  258.            /usr/sunset/md/c++/trainset
  259.  
  260.            The rationale is meant to help keep readers' eyes on what's
  261.            really written in the standard and help them avoid
  262.            misinterpreting it along lines of their own potential
  263.            misconceptions.
  264.  
  265.          - P1003.1b used to have two descriptions of Data Interchange
  266.            formats.  Now it has only one.  The working group picked
  267.            the one that remains because it more closely existing
  268.  
  269. December 1989 Standards Update  IEEE 1003.1: System services interface
  270.  
  271.  
  272.                                 - 6 -
  273.  
  274.            standards in the area, in particular the surviving proposal
  275.            refers to X3.27.
  276.  
  277. December 1989 Standards Update  IEEE 1003.1: System services interface
  278.  
  279.  
  280. Volume-Number: Volume 17, Number 82
  281.  
  282.  
  283.