home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / c / 2393 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  2.9 KB
  1. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!mips!sdd.hp.com!usc!rpi!batcomputer!munnari.oz.au!bruce.cs.monash.edu.au!goanna!ok
  2. From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
  3. Newsgroups: comp.std.c
  4. Subject: Re: does "always append" apply to "a+" mode?
  5. Message-ID: <13851@goanna.cs.rmit.oz.au>
  6. Date: 30 Jul 92 04:15:44 GMT
  7. References: <24992@dog.ee.lbl.gov>
  8. Organization: Comp Sci, RMIT, Melbourne, Australia
  9. Lines: 48
  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. >     Opening a file with append mode (|'a'| as the first character in
  14. >     the |mode| argument) causes all subsequent writes to the file to be
  15. >     forced to the then current end-of-file, regardless of intervening
  16. >     calls to the |fseek| function. ...
  17. > 
  18. > To me, it seems clear that a stream opened in "a+" mode can be read at
  19. > any arbitrary position, but all writes to that stream are appended to
  20. > the underlying file.
  21.  
  22. My understanding of O_APPEND in UNIX (peace; I'll get to the std.c bit soon)
  23. is that every write goes to the end of the file, regardless of where the
  24. file pointer is, and regardless of where the end of the file _was_ last time
  25. we looked.  This means that every time I write a record to such a file, it
  26. is, _at the instant it goes into the file_, the last thing there.
  27.  
  28. It has never been clear to me what the model is for "a" mode.
  29. Is it like Fortran's
  30.     OPEN(UNIT=..., FILE='name', ACTION='WRITE', POSITION='APPEND')
  31. (i.e. is it just like "w" mode except for being _initially_ positioned at
  32. the end of the existing file), or is like like UNIX's
  33.     open("name", O_WRONLY|O_APPEND|O_CREAT)
  34.  
  35. If it is the latter, I don't quite understand how to use it.  In particular,
  36. I don't understand what if any use I can make of ftell() or fgetpos() (there
  37. is where the last write finished, there is where the end of the file is right
  38. now, and there is where the buffered characters will actually go, and those
  39. three places can all be different).  Indeed, it seems to me that there are
  40. just two ways I can use an "a" mode file:
  41.  
  42.     (1)    Assume or ensure that no other process or FILE* refers to the file,
  43.     and treat it as if it was "w" except for seeking to the end instead
  44.     of truncating.
  45.  
  46.     (2)    Assume that other processes _might_ be using the file,
  47.     explicitly use setvbuf() to make sure the buffer is big enough to
  48.     hold a complete formatted record, and _religiously_ use fflush()
  49.     after writing each record (because if I don't do these things,
  50.     the buffer might fragment my logical formatted record, and the
  51.     fragments might be interleaved with fragments from another process).
  52.  
  53. I appreciate that the ANSI standard cannot and should not make promises
  54. about UNIX-specific features sucha s O_APPEND; I'm not so much asking
  55. "can I get access to this feature" as asking "might this feature be used,
  56. and if so, what damage can that do to me".
  57. -- 
  58. You can lie with statistics ... but not to a statistician.
  59.