home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / c / 2378 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  2.5 KB
  1. Path: sparky!uunet!sun-barr!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
  2. From: torek@horse.ee.lbl.gov (Chris Torek)
  3. Newsgroups: comp.std.c
  4. Subject: Re: does "always append" apply to "a+" mode?
  5. Date: 29 Jul 1992 15:01:03 GMT
  6. Organization: Lawrence Berkeley Laboratory, Berkeley
  7. Lines: 49
  8. Message-ID: <25012@dog.ee.lbl.gov>
  9. References: <24992@dog.ee.lbl.gov> <Bs4vLp.A1y@jrd.dec.com>
  10. Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
  11. NNTP-Posting-Host: 128.3.112.15
  12.  
  13. In article <24992@dog.ee.lbl.gov> I wrote:
  14. >>A number of existing implementations that claim POSIX
  15. >>conformance (and hence ANSI X3.159-1989 conformance) do NOT always
  16. >>append with "a+" mode; are they broken?
  17.  
  18. In article <Bs4vLp.A1y@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
  19. >I think that neither paragraph overrides the other.  If the program obeys
  20. >the standard's requirements, then all writes will be appended to the end
  21. >of the file.
  22.  
  23. Thus, these implementations *are* broken.  An example program fragment:
  24.  
  25.     fp = fopen(name, "a+");
  26.     ...
  27.     rewind(fp);
  28.     ret = fwrite(...);    /* replace record at offset 0 */
  29.  
  30. As the comment says, the author expected this `fwrite' call to overwrite
  31. the first few bytes in the file.  On these existing implementations, it
  32. *does*, even though the file is considerably longer.
  33.  
  34. (This was the question.  I am not sure if your answer above is meant
  35. to say that "yes, these implementations are broken".  To name names:
  36.  
  37.     "HP and DEC are certified to have passed POSIX P1003.1 testing and HP
  38.      runs an NIST approved POSIX P1003.1 testing facility. ..."
  39.  
  40. yet these same systems make the above fwrite write at other than EOF.)
  41.  
  42. >If the program does not obey the standard's requirements, then the
  43. >results are undefined.
  44.  
  45. Certainly; that was never the question.
  46.  
  47. >>(As an aside, I have an existence proof that the intermediate seek
  48. >>`feature' is unnecessary, in the form of the 4.3BSD-net.2 stdio.
  49.  
  50. >No.  An example of an implementation with an extension does not prove
  51. >that programs don't have to obey the standard.
  52.  
  53. That is NOT what I meant.  I meant that the historical justification
  54. (`ANSI C requires the seek because you have to seek to reset fp->_cnt')
  55. is ONLY historical; it has no basis in sensibility.  (`Historical'
  56. reasons are certainly good enough for a standard, though given that the
  57. ANSI committee saw fit to fix other existing bugs, I am not sure why
  58. they balked at fixing this one.)
  59. -- 
  60. In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
  61. Berkeley, CA        Domain:    torek@ee.lbl.gov
  62.