After spending all night trying to figure out how file descriptors work, I'm beginning to understand (does anyone else think this is a hard topic to grasp?), I just have one thing i need to help clairfy. Ok so am I right to say that these file descriptors are not necessarily a unique integer for every file, but that try to be by assigning the lowest avaliable integer to a process (besides fd0, fd1, and fd2 as their standard and thus always the same integer). And that the only way that these descriptors portray "uniqueness" is on a per-process-basis. For example a call to the open() system call will give p1 fd3, even though p2 already has fd3 open, because the open() sys call assigns the lowest avaliable fd integer. But if say p1 already had fd3 assigned, then it that case it would have been given fd4 instead, as that would of been the next lowest avalaible fd integer not currently open for that process... To reframe am I wrong and there is in fact fd's integers that cannnot be duplicated? (which would make the reasoning in my post invalid) Is there any point in learning this btw, will it make me a better programmer? Edit: Just learned that fd's are useful when using strace as you can see what config files a program does without having to read the docs (and to learn what it's doing)

Calls such as fopen() return a pointer to a FILE structure in user-space memory. See man 3 fopen.

Any low-level nonces that might be used to refer to an operating-system resource are concealed within that structure and, like the pointer itself, should be regarded as "unpredictable" since Linux runs on many different platforms. (As does libc, for that matter.)

It is most advisable, therefore, to treat any returned value as a nonce: as an unpredictable value having no intrinsic meaning that will "do the job for you," but about which no other assumptions should be made. "Q: How are these values obtained?" "A: It's Magic.™ Don't ask questions, or you might be turned into a Windows user frog."

the file descriptors are a system thing and for normal programming you dont need to worry about them, obviously checking for valid descriptors before using them, the only time i would imagine you needing to knownmore about them, how they are assigned etc is if you are doing kernel or init programming, i have been programming i linux for years and never had to worry about them or learn any more about where they come from how they are assigned etc etc, unless you intend to hack the kernel i wouldn't waste too much time on them

The file descriptor numbers (the value returned by an open() call) are per-process. A file descriptor number in one process has absolutly nothing to do with that same file descriptor number in a different process.

Basically, there's a "layer of software" (in your process) that maintains the file-connections of your process in a set of FILE structures. The exact location of this structure in-memory is both unpredictable and meaningless. Somewhere within that structure will be an actual corresponding operating-system token of some kind that is used when glibc issues physical I/O requests.

All of this should be considered "opaque." You cannot and should not make any assumptions about what these values might be. The operating system can do as it damn well pleases.

(And I happen to know that some "hardened" operating systems deliberately obfuscate these "magic handles" to make it even more difficult to perceive what the operating system is actually doing.)

Ok so i guess this works by Stdio being a layer of abstraction layered over systems calls that allow for more funtionality such as portability due to it being high-level, and possibly improved security... And fopen() utilizes this stdio interface but still needs to call the open() system call before it can provide buffered I/O... The handle in this case is not a discriptor but it's FILE* which is a pointer to the C structure, which is stdin, sdout, and stderr. But the descriptor is wrapped in FILE*, which I guess gets used by fopen() when it does interact with open()...

Yeah or socket() which I guess are the only two system calls that initiate a discriptor?

Thats funny because I found out about them from Julia Evans on youtube, a kernel hacker lol