Opening a file in 'a+ 'mode

Question

If a file is opened using the following command:

FILE *f1=fopen("test.dat","a+");

The man page reads:

a+

Open for reading and appending (writing at end of file). The file is created if it does not exist. The initial file position for reading is at the beginning of the file, but output is always appended to the end of the file.

So does f1 have 2 separate offset pointers, one for read & another for write?

Solution 1

No.

There is just one pointer which initially is at the start of the file but when a write operation is attempted it is moved to the end of the file. You can reposition it using fseek or rewind anywhere in the file for reading, but writing operations will move it back to the end of file.

Solution 2

You can never mix reading and writing operations on a FILE without calling fseek in between. It may work as you wish on some implementations, but a program that depends on this has undefined behavior. Thus the questions of having 2 positions is meaningless.

Solution 3

No it has only one pointer.

Comments

[Daira Hopwood]

It may also be useful to know that this is typically implemented in terms of 'open' with the O_APPEND flag on POSIX systems: pubs.opengroup.org/onlinepubs/7908799/xsh/open.html

[Daira Hopwood]

True. However, if you ever see an operating system's C implementation that supports the POSIX file operations and where the stdio FILE operations are anything other than a thin buffering layer over the POSIX ones (which do have defined behaviour in this case), please report it as a bug against that OS.

[R.. GitHub STOP HELPING ICE]

@DairaHopwood: I'm confused about what you're trying to say. The problem of mixing reading and writing on stdio without an intervening seek is purely an issue of buffering. It has nothing to do with the underlying operations on file descriptors.

[Daira Hopwood]

I mean that I consider a stdio implementation buggy if its undefined behaviour in this case results in anything besides changing where, if at all, buffered data is written. That is, the spec should have been that resulting file contents are implementation-defined, rather than truly undefined behaviour. Otherwise you'll find that a ton of programs have exploitable security bugs.

[R.. GitHub STOP HELPING ICE]

No, it's not buggy. For example, one very nice implementation would be performing __asm__("hlt"); or similar if the caller violates this part of the interface contract. However even if it clobbered memory, that's still not a bug. The bug is in the application that's invoking UB.

[Jon Wheelock]

In case fseek is not called before reading, lot of spaces are printed in the below code. I was expecting nothing to print on screen. But any reason why spaces are printed? That means EOF is not encountered correctly. If I uncomment fseek below, data is correctly printed in the screen. int main() { FILE *fp1; char ch; fp1=fopen("m.txt", "a+"); fputs("data appended", fp1); //fseek(fp1,0,SEEK_SET); while((ch=getc(fp1))!=EOF) { putc(ch,stdout); } fclose(fp1); return 0; }