10

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?

codaddict
  • 445,704
  • 82
  • 492
  • 529

3 Answers3

20

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.

codaddict
  • 445,704
  • 82
  • 492
  • 529
  • It may also be useful to know that this is typically implemented in terms of 'open' with the O_APPEND flag on POSIX systems: http://pubs.opengroup.org/onlinepubs/7908799/xsh/open.html – Daira Hopwood Jul 25 '13 at 15:11
  • 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; }` – Jon Wheelock Jun 07 '16 at 17:38
4

No it has only one pointer.

raj_arni
  • 959
  • 2
  • 15
  • 29
4

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.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • 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. – Daira Hopwood Jul 25 '13 at 15:18
  • @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. – R.. GitHub STOP HELPING ICE Jul 25 '13 at 17:34
  • 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. – Daira Hopwood Jul 26 '13 at 01:03
  • 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. – R.. GitHub STOP HELPING ICE Jul 26 '13 at 06:27