It's UWAweek 44 (2nd semester, 1st exam week)

help2002

This forum is provided to promote discussion amongst students enrolled in CITS2002 Systems Programming.
Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.
Displaying selected article
Showing 1 of 820 articles.
Currently 15 other people reading this forum.


 UWA week 43 (2nd semester, study break) ↓
SVG not supported

Login to reply

👍x1
helpful
8:20pm Thu 24th Oct, Joshua N.

ANONYMOUS wrote:
> Hello,
Hi,
> 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.
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.
> 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."
I'm not allowed to provide the exact answer to the question, but I think you have enough information to provide a good answer.
> 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.
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.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  8:08AM Aug 25 2024
Privacy policy