Hello, I went to see Amitava today to ask him about file pointers vs file descriptors, I understand what a file descriptor is but I was told by Amitava that a file pointer is just a pointer that points at the file descriptor. But other sources on google and the reading provided says something like "When we do any kind of I/O in C, we do so through a piece of data that you get in the form of a FILE* type. This FILE* holds all the information needed to communicate with the I/O subsystem about which file you have open, where you are in the file, and so on." (from https://beej.us/guide/bgc/html/split/file-inputoutput.html#file-inputoutput one of the readings) which seems to indicate that it is more than just a pointer to the file descriptor and stores other information. Im not sure if I misunderstood him or my quesiton wasnt clear enough. If it is the case that its just a pointer to the descriptor why is fopen vs open used in some cases. The question below is the reason i ask, although I did not show Amitava the quesiton when asking him. "With respect to support for file input and output, provided by both the C11 standard library and an operating system, explain the relationship between file pointers and file descriptors. Explain why, or why not, it is possible to mix the use of file pointers and file descriptors within the same C11 program." Another thing is that with the principle of referential locality, is it just the idea that files typically execute sequentially? Because in the final workshop he mentions that its 2 things but doesn't really mention another thing.

ANONYMOUS wrote: File pointers are a higher level more abstract and user friendly system call. It remembers until exactly where you read/wrote on the file and continues where it left off. It uses buffers and is usually more efficient. Principle of referential locality means that memory references (processes in RAM we currently use) usually cluster around each other and there is rarely a jump where we go from A to Z then D, it goes usually A B C D and so on (unless there are function calls). Imagine a list where you iterate from first to last index, if you're at index 2, you would usually use index 3 then 4 and so on. With this, it means that we don't need to load ALL the list, maybe just the first 10 so that we save space for other processes to take place in the RAM. The real challenge here is deciding how much do we constrain this, too much then we won't have as much space for other processes. Too little and page thrasing happens (when the thing you used earlier and will need again keeps getting swapped in and out over and over again). I'm not too sure about file descriptors and pointers and Joshua and Amitava would know better than me but I hope this helps!

I think it's worth noting (and please correct me if you think I'm wrong), that we may have multiple clusters. For example, our code instructions will obviously often cluster particularly when sequential execution, or looping occurs. And independently of this our execution stack data will also cluster for obvious reasons. (We really only need to know the things pushed onto the stack at the time of a function call IE it's parameters, return address and then anything defined locally to the function after that). This can lead to multiple clusters for different sets of information we use in a program. This doesn't really change how we can use the concept if you think about it. It's just worth keeping in mind.

ANONYMOUS wrote: Hi, What Amitava said is correct and so are the other sources (as well as Anon). A file pointer is a pointer to a file structure, which contains useful information that makes reading/writing to files easier. It allows you to treat a file like a "stream" (so you can use fprintf for example) and also provides other useful features like EOF and "where" you currently are in the file. This file stream is built on top of the file descriptor (since the file descriptor is from the OS which is what fundamentally allows us to read and write to files), in other words the file descriptor is stored inside of the file structure (which is what the file pointer points to). Hopefully that makes sense. I'm not allowed to provide the exact answer to the question, but I think you have enough information to provide a good answer. The principle of referential locality isn't strictly related to files. It's just the idea that when we fetch something from memory, it is likely the next thing we need to fetch from memory will be near the memory location we last accessed. E.g. One example of this would be loops, they execute the same instruction repeatedly. So, we would be accessing roughly the same space in memory, using the principle of referential locality we don't have to spend time searching for the next instruction since we know it must be close to the last memory address we accessed. If that makes sense. The two most common types of referential locality are temporal and spatial: Temporal - the exact same memory location we accessed is likely to be used again in the near future. Spatial - it is likely that another memory location near the one we accessed will be needed in the near future. I hope that helps.