What is the concept behind file pointer or the stream pointer?

Question

I know that pointer is a variable that stores address of another variable. So i understood the concepts of char type pointers, integer type pointers, what happens when we add one to a pointer etc. But i didn't get the real concept behind file pointer. Why can't we directly point to them as we do in case of character data type? For eg consider a file with content:

Hello World
fantastic

Let 'ptr' point to this file. Why can't we use the technique ptr to point to 'H', (ptr+1) to 'e', (ptr+2) to 'l' and so on. If my question is stupid, forgive sometimes it would becomes clear if i understand the real concept. I think this file is actually stored in memory just like a string is stored in memory. (I know fscanf() function and all)

Answer 1

There's something called memory mapped file, but this apart, you can achieve what you want (if I understood it correctly) simply opening the file and loading it into a buffer (which is by the way a common way of reading data from files).

Once in memory, you access the first byte with *buf, the second with *(buf+1) and so on; or, usually better since clearer, with buf[0], buf[1] and so on.

Why you can't if you don't use a memory mapped file? Since what you have when you open a file in C (using fopen) is an opaque pointer (i.e. a pointer pointing to data unnknown to you, you must consider it as a "concept" rather than actual data you can read) allowing other functions (fread, fwrite, fseek, and so on) to "operate" on that file you opened, but that pointer does not "contain" the bytes of the file. It is called sometimes handler for a reason: it makes it possibile to "handle" the file.

Using that opaque pointer FILE*, you can read bytes from that file in memory, then you can process the data in memory.

Answer 2

I think you're talking in the context of the C language. No, the file is not actually stored in memory. Think of the file pointer e.g. as a pointer/arrow which shows you how far you're in the process of reading of that file. This means, if you now do a read operation, the pointer tells you which char/int etc. you will read from this file i.e. where you are currently in it. This is what the pointer is for. This is my way of roughly and informally explaining this.

Answer 3

I suppose the basic reason I wouldn't expect ptr+1 to give me the second character of the file is that generally, in C, pointer arithmetic moves you by one object, not one byte; so I would expect ptr+1 to point to the "next" file, whatever that means (if anything).

And files are generally stored on disk, not in memory.

Answer 4

The file is not stored in memory. It can be brought to memory (or parts of it) when you open it. Files are not part of your program's data, they're just an entity you can use with the help of the operating system.

There is a lot more behind files when compared to regular character arrays in memory. Reading from and writing to files is generally buffered, this is handled by the standard C library FILE structure, which lets you invoke operations on a file.

And what would even mean to have a "pointer to a file"? You see, ptr+1 to scan through the file is not a good choice for many reasons. If it's binary data, what exactly do you expect with ptr+1? What if you wanted to read larger chunks of data, like a line at a time?

As you can see, there are several reasons for this choice, the main one being that files are not layed out in memory in your program's address space like regular variables. A structure describing the file and your cursor position is the most common approach.

Another important point to note is that the semantics of ptr+1 make sense for language built-in types only. A file is not a built-in type, and it wouldn't make sense to be.