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?

Forgave

Answer 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.

Affection

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 – Rebirth

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; } – Serg

Answer 2

No it has only one pointer.

Currycomb

Answer 3

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.

Wipe

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. – Rebirth

@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. – Wipe

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. – Rebirth

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. – Wipe