home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v9 / text0047.txt < prev    next >
Encoding:
INI File  |  1987-06-30  |  3.0 KB  |  78 lines
  1. [ The results of the Weirdnix contest (to find legal misinterpretations
  2. of the POSIX Trial Use Standard) were announced at the USENIX Conference
  3. a couple of weeks ago in Washington, D.C., by me and Jim McGinness.
  4. Unfortunately, we did not have the full text of the winning entries
  5. at the time.  However, I promised to post them here.  Donn Terry,
  6. the P1003 co-chair and an originator of the contest, has supplied
  7. them in this posting.  -mod ]
  8.  
  9. The Weirdnix winners' proposals appear below. 
  10.  
  11. The winner in the most serious category was Paul Gootherts of HP.
  12.  
  13. Problem:
  14.     The definition of sleep() is inconsistent.
  15.  
  16. Explanation:
  17.     "The value returned by the sleep() function shall be the unslept
  18.     amount (the requested time minus the time actually slept)."
  19.     [Para 3.4.3.3]
  20.  
  21.     "The suspension time may be longer than requested by an
  22.     arbitrary amount due to the scheduling of other activity in the
  23.     system."
  24.     [Para 3.4.3.2]
  25.  
  26.     Since the time actually slept can be greater than the time
  27.     requested, the value returned could be negative.  However,
  28.     sleep() returns an unsigned int.
  29.     [Para 3.4.3.1]
  30.  
  31. Proposal:
  32.     Sleep() could be changed to return a signed int.  This is nice
  33.     because the process that called it could get some idea of how
  34.     "late" the alarm came.
  35.  
  36.     Alternatively, the routine could be documented to return zero if
  37.     the actual time was greater than the requested time.
  38.  
  39. Paul Gootherts
  40. Hewlett Packard, ITG/ISO/HP-UX, hpda!pdg
  41.  
  42. ------------------------------------------------------------------------
  43. In the most demented category:
  44.  
  45. >From Michael Gersten.  (michael@stb from what I can determine from the
  46. mixed address I have; as I write this I havn't succeeded in contacting
  47. him yet.)  (Michael: please write me at hplabs!hpfcla!donn.)
  48.  
  49.  
  50. Ok, let's look at read() and write().
  51. 1. There is no requirement that anything written will be available for a
  52. read().
  53. 2. There is no requirement that read/write return everything that they can.
  54.  
  55. In general, you can't require this. The terminal lines are a good example; 
  56. writing to a terminal will not result in it being readable; the terminal
  57. drivers only return a line at a time no matter how much is requested. Or
  58. at least, that's what the docs say (I've never actually tested it, but it
  59. seems that if it were false, then type-ahead would not work as well.)
  60.  
  61. In general, it is probably safe to require that anything written to a file
  62. should be available to a subsequent read provided that the read is done on
  63. a file descriptor corresponding to the same name, or a link to the same
  64. named file that was written to, all providing that it is a regular file.
  65. Certainly not for device or special files.
  66.  
  67. Incidently, don't think that 2 is obvious; my first unix programs assumed
  68. that the O/S would return a number of bytes so that the reads would be
  69. re-aligned on a 512 byte boundary, and that I had to call read() multiple
  70. times until I had gotten everything. I was quite suprised to find that
  71. other people had written stuff that did not do this, and even more
  72. suprised to find that it actually worked. No :-)
  73.  
  74.         Michael Gersten
  75.  
  76. Volume-Number: Volume 9, Number 48
  77.  
  78.