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