home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!think.com!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
- From: torek@horse.ee.lbl.gov (Chris Torek)
- Newsgroups: comp.lang.c
- Subject: Re: Appending To A File
- Date: 24 Nov 1992 01:48:48 GMT
- Organization: Lawrence Berkeley Laboratory, Berkeley
- Lines: 40
- Message-ID: <27628@dog.ee.lbl.gov>
- References: <1992Nov20.192627.8533@nosc.mil>
- Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
- NNTP-Posting-Host: 128.3.112.15
-
- In article <1992Nov20.192627.8533@nosc.mil> mitch@nosc.mil
- (Ray Mitchell) writes:
- >rewinding, then attempting to write to a file opened in the "a+" mode.
-
- [various sample outputs deleted]
-
- The UNIX version tested in the original article fails to conform; the
- MS-DOS Borland and Microsoft outputs conform to the ANSI standard.
-
- >... I guess my question boils down to what the rewind (and I assume
- >all the other positioning functions) are supposed to do in the "a+"
- >mode.
-
- Stdio positioning functions have two effects:
-
- a) They reposition the file for the next input or output
- operation.
- b) They reset `+'-mode files so that the next operation may
- be either input or output. Once I/O is begun, another file
- position operation is needed to `change directions'. (Some
- implementations, such as my own, waive the right to demand
- such a positioning operation, but other significant existing
- C libraries required it, so it got put into the ANSI C
- standard.)
-
- Now, in the case of `a'ppend mode, all writes are supposed to be
- appended to the file, regardless of any intervening fseek, fsetpos,
- or rewind operation. Thus, for "a+" mode, only effect (b) above
- is relevant.
-
- If you want to append to a file, with the option of replacing the
- appended text within the same run, you must open the file in "r+" mode
- (or "w+" if it does not yet exist), position to the end with fseek(),
- remember that position with fgetpos, append, and then return to it with
- fsetpos. Note that some systems will impose strange restrictions on
- `position to the end', such as requiring that `the end' always be a
- multiple of 512 bytes.
- --
- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
- Berkeley, CA Domain: torek@ee.lbl.gov
-