What's the difference between a file descriptor and file pointer?

I want to know the difference between a file descriptor and file pointer.

Also, in what scenario would you use one instead of the other?

A file descriptor is a low-level integer "handle" used to identify an opened file (or socket, or whatever) at the kernel level, in Linux and other Unix-like systems.

You pass "naked" file descriptors to actual Unix calls, such as read(), write() and so on.

A FILE pointer is a C standard library-level construct, used to represent a file. The FILE wraps the file descriptor, and adds buffering and other features to make I/O easier.

You pass FILE pointers to standard C functions such as fread() and fwrite().

One is buffered (FILE *) and the other is not. In practice, you want to use FILE * almost always when you are reading from a 'real' file (ie. on the drive), unless you know what you are doing or unless your file is actually a socket or so..

You can get the file descriptor from the FILE * using fileno() and you can open a buffered FILE * from a file descriptor using fdopen()

A file descriptor is just an integer which you get from the POSIX open() call. Using the standard C fopen() you get a FILE struct back. The FILE struct contains this file descriptor amongst other things such as end-of-file and error indicator, stream position etc.

So using fopen() gives you a certain amount of abstraction compared to open(). In general you should be using fopen() since that is more portable and you can use all the other standard C functions that uses the FILE struct, i.e., fprintf() and family.

There are no performance issues using either.

File descriptor vs File pointer

File descriptor:

File Descriptor is an integer value returned by open() system call.

int fd = open (filePath, mode);

1. Low/Kernel level handler.
2. passe to read() and write() of UNIX System Calls.
3. Doesn't include buffering and such features.
4. Less portable and lacks efficiency.

File pointer:

File Pointer is a pointer to a C structure returned by fopen() library function, which is used to identifying a file, wrapping the file descriptor, buffering functionality and all other functionality needed for I/O operation.The file pointer is of type FILE, whose definition can be found in "/usr/include/stdio.h". This definition may vary from one compiler to another.

FILE *fp = fopen (filePath, mode);

// A FILE Structure returned by fopen 
	typedef struct 
	{
        unsigned char   *_ptr;
        int     _cnt;
        unsigned char   *_base;
        unsigned char   *_bufendp;
        short   _flag;
        short   _file;
        int     __stdioid;
        char    *__newbase;
#ifdef _THREAD_SAFE
        void *_lock;
#else
        long    _unused[1];
#endif
#ifdef __64BIT__
        long    _unused1[4];
#endif /* __64BIT__ */
	} FILE;

1. It is high level interface.
2. Passed to fread() and fwrite() functions.
3. Includes buffering,error indication and EOF detection,etc.
4. Provides higher portability and efficiency.

Want to add points which might be useful.

ABOUT FILE *

1. can't be used for interprocess communication(IPC).

2. use it when you need genral purpose buffered I/O.(printf,frpintf,snprintf,scanf)

3. I use it many times for debug logs. example,

               FILE *fp;
               fp = fopen("debug.txt","a");
               fprintf(fp,"I have reached till this point");
               fclose(fp);
   

ABOUT FILE DESCRIPTOR

1. It's generally used for IPC.

2. Gives low-level control to files on *nix systems.(devices,files,sockets,etc), hence more powerfull than the FILE *.

FILE * is more useful when you work with text files and user input/output, because it allows you to use API functions like sprintf(), sscanf(), fgets(), feof() etc.

File descriptor API is low-level, so it allows to work with sockets, pipes, memory-mapped files (and regular files, of course).

Just a note to finish out the discussion (if interested)....

fopen can be insecure, and you should probably use fopen_s or open with exclusive bits set. C1X is offering x modes, so you can fopen with modes "rx", "wx", etc.

If you use open, you might consider open(..., O_EXCL | O_RDONLY,... ) or open(..., O_CREAT | O_EXCL | O_WRONLY,... ).

See, for example, Do not make assumptions about fopen() and file creation.

I found a good resource here, giving high level overview of differences between the two:

>When you want to do input or output to a file, you have a choice of two basic mechanisms for representing the connection between your program and the file: file descriptors and streams. File descriptors are represented as objects of type int, while streams are represented as FILE * objects. > >File descriptors provide a primitive, low-level interface to input and output operations. Both file descriptors and streams can represent a connection to a device (such as a terminal), or a pipe or socket for communicating with another process, as well as a normal file. But, if you want to do control operations that are specific to a particular kind of device, you must use a file descriptor; there are no facilities to use streams in this way. You must also use file descriptors if your program needs to do input or output in special modes, such as nonblocking (or polled) input (see File Status Flags). > >Streams provide a higher-level interface, layered on top of the primitive file descriptor facilities. The stream interface treats all kinds of files pretty much alike—the sole exception being the three styles of buffering that you can choose (see Stream Buffering). > >The main advantage of using the stream interface is that the set of functions for performing actual input and output operations (as opposed to control operations) on streams is much richer and more powerful than the corresponding facilities for file descriptors. The file descriptor interface provides only simple functions for transferring blocks of characters, but the stream interface also provides powerful formatted input and output functions (printf and scanf) as well as functions for character- and line-oriented input and output. > >Since streams are implemented in terms of file descriptors, you can extract the file descriptor from a stream and perform low-level operations directly on the file descriptor. You can also initially open a connection as a file descriptor and then make a stream associated with that file descriptor. > >In general, you should stick with using streams rather than file descriptors, unless there is some specific operation you want to do that can only be done on a file descriptor. If you are a beginning programmer and aren’t sure what functions to use, we suggest that you concentrate on the formatted input functions (see Formatted Input) and formatted output functions (see Formatted Output). > >If you are concerned about portability of your programs to systems other than GNU, you should also be aware that file descriptors are not as portable as streams. You can expect any system running ISO C to support streams, but non-GNU systems may not support file descriptors at all, or may only implement a subset of the GNU functions that operate on file descriptors. Most of the file descriptor functions in the GNU C Library are included in the POSIX.1 standard, however.

System calls are mostly using file descriptor, for example read and write. Library function will use the file pointers ( printf , scanf). But, library functions are using internally system calls only.