This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
C fopen vs open
What is the difference between open() and fopen() in C language?
One is part of the standard c library (fopen) so you can expect it to be present on all hosted c compiler setups. This function returns a FILE* which can be operated on by the functions in <stdio.h>.
The other (open) is a system call/function not specified by the c standard (however, i believe it is part of the POSIX standard) and therefore only guaranteed to exist on select platforms which claim to support it. This returns an int which represents a file, this can be operated on using read/write and other similar functions.
open() is a standardised system call provided by a POSIX compliant operating system (most POSIX-like operating systems also have the open() system call). fopen() is a C library function provided by the C implementation and/or runtime library.
fopen() allows for buffered and/or formatted input/output, whereas open() is generally used for more straightforward IO. It is possible for the fopen() function to be implemented using the open() system call.
As others said open() is a system call through POSIX standard, mostly supported by UNIX family of operating systems. It returns 'int' indicating the file descriptor being opened.
While on the other hand fopen() is provided by C-library and it returns a FILE* pointing to the file being opened.
Related
I have no issues with the library functions. I know that they work well. I am interested in their implementation. My question is: Can I write working versions of these functions for Windows x64 using only C?
Many of the stnadard library functions are written in C, and fopen, fread etc. are no exception. You can write a wrapper around open, read, write etc. which are usually lower level functions.
If those are not available, you can also do the same, calling the respective OS functions and wrapping them with your own implementation, you just have to make sure that they are complying to the standard.
Just as an example you can find a source for fopen here.
In Linux API, fcntl() can be very useful to get or set file descriptor flags, file status flags, and other properties.
In the C standard library, is there a similar function to fcntl() which can get or set the properties of a FILE object, and its underlying file descriptor flags, file status flags, and other properties?
No. That's because, in the ISO C standard, FILE-based processing is the lowest level API specified. It's not necessary that file descriptors (and the other things you mention) even exist.
How it's handled "under the covers" is totally dependent on the implementation, so you have to revert to implemntation-specific stuff if you want access to its information.
The POSIX standard actually mandates the underlying mechanisms and many C implementations also support POSIX but it's by no means required by ISO C, the one true C standard :-)
If you have fcntl in the first place, then you should also have two other functions which let you go back and forth between bare file descriptors and FILE objects: fileno and fdopen. None of these functions are specified by ISO C (hence they are not part of the standard C library) but they are all included in the POSIX standard (which defines most of what it means to be a "Unix"), so if you have one of them you can expect to have all three. The header fcntl.h is also part of that standard.
Why is there no dscanf function for reading from file descriptors?
We have fprintf, sprintf and dprintf for printing but for scanning there is only fscanf and sscanf.
It is not possible to write dscanf.
The scanf family requires that the stream is buffered, or else that it is capable of putting back a character that was read. POSIX file descriptors are neither.
Consider this stream
1234xyz
How would you scan a number off it? You cannot read it byte by byte and stop just before x. That would require clairvoyance. You also cannot read x and decide you don't need it, because you cannot put it back.
Because the printf and scanf family of functions is part of the C language, the functions handling file descriptors are not. Instead they are part of the operating system API (on POSIX platforms like Linux or OSX, other platforms emulate these system calls).
And the dprintf function is not a standard C function, it's an extension. From this printf (and family) manual page:
The dprintf() and vdprintf() functions were originally GNU extensions that were later standardized in POSIX.1-2008.
That there's no dscanf function is probably just an oversight from those who made the original dprintf extension.
I want to know what happen when compiler encountered "fopen()" in C program.
Where is the function which calls the 'open' system call?
I see fopen() is declared in stdio.h, but I cannot find where it is implemented!!
I want to see where system call number and other parameters of system calls are written to CPU registers.
Thank you.
You can look at glibc implementation here: https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/iofopen.c;h=be2bbb663bc04093493313af266fcdad85c62c28;hb=HEAD#l95
_IO_new_fopen is a symbolic constant (macro) that expands to fopen The fopen function is a wrapper around an internal function to a libio function.
fopen isn't a system call, you might be confusing it with open which is a system call.
I know that read is system call. But when I read man 2 and man 3 of read it shows me different explanation. So , I am suspecting that read has library function and system call. In such case if I use read in my c program, whether compiler will consider read as library function or system call Please explain me on this confusion.
It doesn't. System calls are present in libc (the C standard library) just like library functions are. The implementations of system calls in libc are just "stubs" which invoke system-specific methods of calling into the kernel.
I'm assuming you're on Linux. On that platform, the manpage read(2) describes the Linux system call, while read(3) describes the POSIX specification for read, if you have the POSIX manpages installed. The latter is in category 3 because POSIX doesn't specify a difference between system calls and library functions.
There's only one read in libc, which is (a thin wrapper around) the system call.