Shulou(Shulou.com)06/02 Report--

This paper mainly studies the conversion between file descriptor fd and file pointer FILE* in Linux, which is introduced in detail as follows.

1. Definition of the file descriptor FD: the file descriptor is formally a non-negative integer. In fact, it is an index value that points to the record table of files opened by the kernel for each process maintained by that process. When a program opens an existing file or creates a new file, the kernel returns a file descriptor to the process. In programming, some low-level programs are often written around file descriptors. But the concept of file descriptor is often only applicable to operating systems such as UNIX and Linux.

two。 File pointer FILE defines that the general form of a file pointer is:

FILE * pointer variable identifier

Where FILE should be uppercase, it is actually a structure defined by the system, which contains information such as file name, file status and file current location. You don't have to care about the details of the FILE structure when writing source programs.

File descriptors are often used when using system calls, but the operation is more primitive. The C library functions provide some convenient wrappers (such as formatting Imax O, redirecting) on Imax O, but do not have enough control over the details.

If you rely too much on one of them, it will only add to the trouble, so it is necessary to know the conversion between the two. FILE* is the encapsulation of fd

Of course, some people will say that if you know the file path, then reopen it, but this will create a competitive condition (Race Conditions), first reopen the file, equivalent to two fd pointing to the same file, and then if the file is deleted and a new file with the same name is created during the opening period, the two fd points to a different file.

The glibc library provides two conversion functions, fdopen (3) and fileno (3), both of which are in

FILE * fdopen (int fd, const char * mode)

Int fileno (FILE * stream)

PS: to save space, continue to ignore the return value check.

Let's take a look at the test and see if it's what we thought.

# include # include # include int main () {const char* filename = "new.txt"; int fd= open (filename, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR); FILE* fp = fdopen (fd, "w +"); int fd2= fileno (fp); printf ("fd=%d | fd2=%d\ n", fd, fd2); fclose (fp); close (fd); return 0;} $gcc test.c $. / a.out fd=3 | fd2=3

Refer to the fileno manual:

The function fileno () examines the argument stream and returns its integer descriptor.

FILE is the encapsulation of fd, and fileno () takes the encapsulated fd directly, so no new fd is created to point to the file.

Refer to the fdopen manual:

The fdopen () function associates a stream with the existing file descriptor, fd. The mode of

The stream (one of the values "r", "r +", "w", "w +", "a", "a +") must be compatible with the

Mode of the file descriptor.

Fdopen () is that the stream (FILE object) is associated with the existing file descriptor fd, so no new fd is created. It is worth noting that the schema of the FILE pointer (mode) must be compatible with the schema of the file descriptor.

With regard to the mode parameters for a while, what we know is that the conversion using fileno and fdopen operates on the original fd and does not generate a new fd. So, if you look at the code again, do you find a problem?

Let's check the return value of close (fd) and change close (fd) to the following code

If (- 1 = = close (fd)) {perror ("close"); exit (1);} $gcc test.c $. / a.out close: Bad file descriptor

Yes, when fclose closes the file pointer, it also closes the file descriptor internally (otherwise the resources will be leaked). Since the file descriptor inside fp is the same as fd, when fp is closed, fd is also closed, closing fd again will result in a "corrupted file descriptor" error.

OK, now let's review the second parameter of fopen, and there are six settings (rb/rb+/wb/wb+ for windows platform aside). Compared with the Linux manual, I will list the corresponding open settings.

Still do the test. Modify fd_mode and fp_mode to see the experimental results.

# include # include const int security = S_IRUSR | O_RDWR Const int fd_mode = O_RDWR | O_CREAT | OneTrunk Const char* fp_mode = "r"; int main () {int fd = open ("new.txt", fd_mode, security); FILE* fp = fdopen (fd, fp_mode); if (fp = = NULL) {perror ("fdopen"); exit (1);} close (fd); return 0;}

When fd_mode is equivalent to "w +", the six settings of fp_mode (rqqpxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) all return a non-null pointer.

When fd_mode is equivalent to "w", only "a" and "w" settings of the fp_mode6 type return non-null pointers.

If you continue to try the setting of "r" / "r +" / "a" / "a +", you can find that the so-called "compatibility" is only related to read and write permissions, O_RDWR is compatible with O_RDONLY and O_WRONLY, and the latter two are only compatible with themselves.

Interestingly, O_APPEND (added at the end) and O_TRUNC (truncated file added from scratch) are also compatible.

The file position indicator of the new stream is set to that

Belonging to fd, and the error and end-of-file indicators are cleared. Modes "w" or "w +" do

Not cause truncation of the file. The file descriptor is not dup'ed, and will be closed when

The stream created by fdopen () is closed.

Continuing to look at the contents of the fdopen manual, you can see that "w" and "w +" do not cause file truncation here.

The latter sentence also confirms our previous experimental results: the file descriptor will not be copied and the file descriptor will be closed when the file pointer is closed.

PS: in fact, there is the last sentence in fdopen's manual: The result of applying fdopen () to a shared memory object is undefined.

The result of using fdopen for shared memory objects is undefined.

Summary

The above is about the Linux file descriptor fd and file pointer FILE* conversion instance parsing all the content, I hope to help you. Interested friends can continue to refer to other related topics on this site, if there are any deficiencies, please leave a message to point out. Thank you for your support to this site!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.