home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / c / 2388 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  3.7 KB
  1. Path: sparky!uunet!mcsun!uknet!acorn!ixi!clive
  2. From: clive@x.co.uk (Clive Feather)
  3. Newsgroups: comp.std.c
  4. Subject: Re: does "always append" apply to "a+" mode?
  5. Message-ID: <1992Jul30.143420.24848@x.co.uk>
  6. Date: 30 Jul 92 14:34:20 GMT
  7. References: <24992@dog.ee.lbl.gov>
  8. Organization: IXI Limited, Cambridge, UK
  9. Lines: 82
  10.  
  11. In article <24992@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
  12. > In the section on fopen (4.9.5.3, pp. 130--131), the Standard says:
  13. >
  14. >    Opening a file with append mode (|'a'| as the first character in
  15. >    the |mode| argument) causes all subsequent writes to the file to be
  16. >    forced to the then current end-of-file, regardless of intervening
  17. >    calls to the |fseek| function. ...
  18. >
  19. >    When a file is opened with update mode (|'+'| as the second or
  20. >    third character in the above list of |mode| argument values), both
  21. >    input and output may be performed on the associated stream.
  22. >    However, [switching directions requires an intervening reposition
  23. >    or flush or EOF].
  24. >
  25. > To me, it seems clear that a stream opened in "a+" mode can be read at
  26. > any arbitrary position, but all writes to that stream are appended to
  27. > the underlying file.  There is some dissent, however, on the grounds
  28. > that the second paragraph `overrides' the first, i.e., that the first
  29. > paragraph does not apply because of the '+' character.
  30.  
  31. The dissenters have no ground to stand on. For an a+ mode file, the
  32. second paragraph requires an fseek or similar action between reading
  33. and writing, while the first paragraph says that this fseek will not
  34. alter the effects of the write, which is to EOF.
  35.  
  36. In other words, the sequence:
  37.  
  38.     fread
  39.     fseek  /* to anywhere */
  40.     fwrite
  41.  
  42. will always append to the file. The effect of the second paragraph is
  43. that the sequence:
  44.  
  45.     fread
  46.     fwrite
  47.  
  48. has an undefined effect (and Chris knows better than I do what that
  49. means :-).
  50.  
  51. > As I understand it, the seek/flush/EOF requirement for direction-
  52. > changing is a direct result of existing Unix (and possibly other)
  53. > implementations, where an intervening seek is required to `sync up'
  54. > internal counters and set a read/write stream's mode to
  55. > `indeterminate', so that the next getc or putc macro will trigger a
  56. > function call, where the new direction will be set.  It is not meant
  57. > to imply that seeks have any effect on "a+" mode files.
  58. > Is this correct?
  59.  
  60. You are correct.
  61.  
  62. > A number of existing implementations that claim POSIX
  63. > conformance (and hence ANSI X3.159-1989 conformance) do NOT always
  64. > append with "a+" mode; are they broken?
  65.  
  66. If the implementation claims conformance to "POSIX.1, C Language Binding
  67. (C Standard Language-Dependent System Support)", then the implementation
  68. is broken (but see below).
  69.  
  70. If the implementation claims conformance to "POSIX.1, C Language Binding
  71. (Common-Usage C Language-Dependent System Support)", then the implementation
  72. is broken unless its Conformance Document clearly describes the
  73. different behaviour.
  74.  
  75. If the implementation claims conformance to IEEE 1003.1-1988
  76. (_POSIX_VERSION_ == 198808L) then the "C standard" refers to the
  77. 1988-05-13 draft (X3J11/88-002). If it claims conformance to ISO/IEC
  78. 9945-1:1990 (a.k.a. IEEE 1003.1-1990) (_POSIX_VERSION == 199009L) then
  79. the C standard is ISO/IEC 9899:1990. I don't know if these two differ in
  80. their handling of this case.
  81.  
  82. > (As an aside, I have an existence proof that the intermediate seek
  83. > `feature' is unnecessary,
  84.  
  85. Unnecessary for an implementation, perhaps. It is still necessary for
  86. any conforming application.
  87.  
  88. -- 
  89. Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
  90. clive@x.co.uk          | 62-74 Burleigh St.  | it will get its revenge.
  91. Phone: +44 223 462 131 | Cambridge   CB1 1OJ |   - Henry Spencer
  92. Fax:   +44 223 462 132 | United Kingdom      |
  93.