home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v1 / text0005.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.7 KB

  1. From: John Quarterman (moderator) <ut-sally!std-unix>
  2.  
  3. Before the Portland USENIX Conference, or, more specifically, before
  4. the P1003 "UNIX Standards" committee meeting which was held on the
  5. three days before that USENIX, I solicited comments and questions about
  6. the P1003 standard on several newsgroups on USENET.  Here are most of
  7. the questions and my interpretation of how they relate to what the
  8. committee is doing.  Be aware that my interpretation may not correspond
  9. to reality, and is certainly not an official statement by the committee.
  10.  
  11. Is the P1003 draft standard compatible with the X3J11 C draft standard?
  12.  
  13.     This was one of the main things discussed at the meeting.
  14.     The P1003 committee is very concerned about compatibility
  15.     with X3J11, to the point of replacing large sections of
  16.     the P1003 draft standard with references to the X3J11 standard.
  17.     There are places where it's not that simple, though, such as
  18.     kill(2), because the C standard needs to define a small set
  19.     of functions, while the P1003 standard needs to define others.
  20.     A committee was appointed to communicate with X3J11.
  21.  
  22.     Someone asked specifically if <limits.h> would be compatible,
  23.     and the intention of the committee is that it will be.
  24.  
  25.     Someone else asked if signal(2) were defined properly using void.
  26.     At the moment, it's not.  I don't know if it will be later.
  27.  
  28. Database issues.
  29.  
  30.     File locking was referred to a /usr/group subcommittee,
  31.     which solicited members at a USENIX BOF.  This was because
  32.     the P1003 members are mostly not database experts, and
  33.     felt that problems with lockf could not be resolved by them
  34.     in a reasonable amount of time.  The committee did remove
  35.     the enforcement mode of lockf from the body of the draft
  36.     to an appendix.
  37.  
  38.     The 4.2BSD truncate system call is not in the draft standard,
  39.     and thus far no one has proposed that it should be.  Though
  40.     its utility is clear, there seems to be a strong reluctance
  41.     to add new facilities.
  42.  
  43. Are the 4.2BSD directory routines (opendir, readdir, closedir) included?
  44.  
  45.     They were recently added, in an appendix.
  46.  
  47.     Someone asked if the conflicts involving <sys/ndir.h> having
  48.     the same name but different functions on 4.2BSD and other
  49.     systems had been resolved.  The corresponding header file
  50.     is <dirent.h> in the draft standard.
  51.  
  52. Have windowing, graphics, or network standards been addressed?
  53.  
  54.     The committee takes pains to avoid precluding network
  55.     implementations of things such as file systems, but
  56.     does not directly address windowing, graphics, or networks.
  57.     There are /usr/group subcommittees on those subjects, however.
  58.  
  59.     If someone more knowledgeable would post something on the
  60.     /usr/group committees, I would appreciate it.
  61. -- 
  62.  
  63. John Quarterman, jsq@ut-sally.ARPA, {ihnp4,seismo,ctvax}!ut-sally!jsq
  64.  
  65. Volume-Number: Volume 1, Number 06
  66.  
  67.