This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What's the difference between a file descriptor and file pointer?
If I open file like this:
FILE *fp = fopen("mr32.txr","r");
then fp is file pointer or file descriptor? What is difference between them?
fp is a FILE pointer
File pointer:
It is high level interface
Passed to fread() and fwrite() functions
Includes buffering,error indication and EOF detection,etc.
Provides higher portability and efficiency.
File descriptor:
Low/Kernel level handler
passe to read() and write() of UNIX System Calls
Doesn't include buffering and such features
Less portable and lacks efficiency
based on this link
It's a pointer to a FILE structure, if that's what you're asking. A file descriptor is an integer. The FILE structure and its related APIs are part of the C standard. File descriptors and their related functions are not. In practice you can use either set of functions interchangeably, though there are some notable differences in default behaviour here and there. You can read the man pages to figure out which functions take which sort of parameters. On systems that have file descriptors, you can usually use the fdopen(3) function to get a FILE structure from an open file descriptor and fileno(3) to go the other way.
FILE is a struct that contains information about the file, including the file descriptor.
Related
I have one question of temporary file open in C program.
I know there is FOPEN_MAX in stdio.h. As far as I know, FOPEN_MAX is the number of files(not temporary) can be opened simultaneously in C program. But, If I make temporary file using 'tmpfile()', does the number of temporary files included in FOPEN_MAX ?
Thanks in advance.
It is not written explicitly, but it seems the limitation is the same, no matter if file is temporary or not.
https://www.opennet.ru/man.shtml?topic=tmpfile&category=3&russian=5
See error code for tmpfile():
EMFILE
{FOPEN_MAX} streams are currently open in the calling process.
Is there anything like a string file in stdio/string/stdlib ? I mean a special way to fopen a FILE stream, which actually directs the writes to an internal buffer and takes care of buffer allocation/reallocation ? After fclose, the text should be available as null-terminated char[] or similar.
I need to interface to legacy code that receives a FILE* as an argument and writes to it, and I'd prefer to avoid writing to a temporary disk file.
Other forms of storage could do instead of char[] (f.i. string), but a FILE* pointer must be available.
I am looking for an alternative to creating a temporary disk file.
fmemopen & open_memstream are in the POSIX 2008 standard, probably inspired by GNU libc string streams, and give in-memory FILE* streams.
See also this question quite similar to yours, and also that answer.
BTW, many operating systems have RAM based or virtual memory based filesystems (à la tmpfs)
If you are coding in C++11 (not in C) and perhaps for some earlier C++ standard you can of course use std::stringstream-s
So you could use open_memstream on Posix, and some other solution on Windows (just with #if _POSIX_C_SOURCE > 200809L per feature_test_macros(7) ...)
The C standard does not provide (yet) any in-memory FILE streams, so if you need them you have to code or use platform-specific functions.
Create the temporary file using CreateFile(... FILE_ATTRIBUTE_TEMPORARY, FILE_FLAG_DELETE_ON_CLOSE ...) and then convert the HANDLE to FILE*.
You said you didn't like a write to a temporary file, so these flags to CreateFile are a strong hint to Windows to keep the file in cache if possible. And if Windows would run of of RAM, even a char[] can end up in a swap file anyway.
I am looking for a alternative for declaring the file pointer without using "FILE * pointer", so I mean without using the IO standard library function, maybe as a function.
With the library its easy but how could the function look like without the library.
Can somebody give an advice?
glibc includes a low-level file API for handling files with int file descriptors.
In fact, I think if you were to cast a FILE* to an integer in the glibc implementation, you would obtain a file descriptor usable with the low-level file API, and vise versa.
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.
Given a stdio FILE * pointer, is there a method by which I can discover the name of the (opened) file?
It looks (from here) that on POSIX systems you can use fileno() to get the file descriptor from a FILE*, then use fstat to get the stat info from the file descriptor. The stat structure contains the device number and inode number. You can check the filesystem for files which match the inode. This will obviously take some time for a filesystem full of stuff.
The reason that this isn't really possible (as explained in the linked article) is that a stream can have no filename if it's something like stdin or stdout, or if it's an open file that has been deleted. It can have multiple names because of hardlinks as well.
The linked article mentions this comp.lang.c FAQ which outlines the insolubility of this problem in brief.
EDIT: Thanks for the correction.
No, there isn't. Apart from anything else, the FILE * may not refer to a named file. If your application needs this facility, you wil need to maintain some kind of map
from open FILE *s to the file name you used to open them.
There is no standard defined portable solution. However, you can take a look at your OS provided API set. POSIX systems have a fstat function that takes a descriptor (not a FILE *) and returns some information.