Why can't I use fopen?

Question

In the mold of a previous question I asked about the so-called safe library deprecations, I find myself similarly bemused as to why fopen() should be deprecated.

The function takes two C strings, and returns a FILE* ptr, or NULL on failure. Where are the thread-safety problems / string overrun problems? Or is it something else?

Thanks in advance

Answer 1

The new versions do parameter validation whereas the old ones didn't.

See this SO thread for more information.

Answer 2

Thread safety. fopen() uses a global variable, errno, while the fopen_s() replacement returns an errno_t and takes a FILE** argument to store the file pointer to.

Answer 3

You can use fopen(). Seriously, don't take any notice of Microsoft here, they're doing programmers a real disservice by deviating from the ISO standards. They seem to think that people writing code are somehow brain-dead and don't know how to check parameters before calling library functions.

If someone isn't willing to learn the intricacies of C programming, they really have no business doing it. They should move on to a safer language.

This is just another attempt at vendor lock-in by Microsoft of developers (although they're not the only ones who try it; I'm not specifically berating them). I usually add:

#define _CRT_SECURE_NO_WARNINGS

(or the "-D" variant) to most of my projects to ensure I'm not bothered by the compiler when writing perfectly valid, legal C code.

Microsoft has provided extra functionality in the fopen_s() function (file encodings, for one) as well as changing how things are returned. This may make it better for Windows programmers but makes the code inherently unportable.

You can tell from the prototype why they've changed this one. The fact that they're returning an errno and setting the file handle using double indirection almost certainly indicates that they think the real fopen() has a threading issue with the global errno:

errno_t fopen_s( 
    FILE** pFile,
    const char *filename,
    const char *mode 
);

Why they didn't just define errno as a function call (to return a thread-specific error) or a field in a thread-specific data structure like every other implementation is beyond me.

Aside: According to some comments, they do define errno to be thread-specific. This seems to indicate that the sole purpose of the "safe" version is the extra functionality.

If you're only ever going to code for Windows, by all means use it. I myself prefer the ability to compile and run my code anywhere (with as little change as possible).

Answer 4

Or is it something else?

Some implementations of the FILE structure used by 'fopen' has the file descriptor defined as 'unsigned short'. This leaves you with a maximum of 255 simultaneously open files, minus stdin, stdout, and stderr.

While the value of being able to have 255 open files is debatable, of course, this implementation detail materializes on the Solaris 8 platform when you have more than 252 socket connections! What first appeared as a seemingly random failure to establish an SSL connection using libcurl in my application turned out to be caused by this, but it took deploying debug versions of libcurl and openssl and stepping the customer through debugger script to finally figure it out.

While it's not entirely the fault of 'fopen', one can see the virtues of throwing off the shackles of old interfaces; the choice to deprecate might be based on the pain of maintaining binary compatibility with an antiquated implementation.

Answer 5

There is an official ISO/IEC JTC1/SC22/WG14 (C Language) technical report TR24731-1 (bounds checking interfaces) and its rationale available at:

• http://www.open-std.org/jtc1/sc22/wg14

There is also work towards TR24731-2 (dynamic allocation functions).

The stated rationale for fopen_s() is:

6.5.2 File access functions

When creating a file, the fopen_s and freopen_s functions improve security by protecting the file from unauthorized access by setting its file protection and opening the file with exclusive access.

The specification says:

6.5.2.1 The fopen_s function

Synopsis

#define __STDC_WANT_LIB_EXT1__ 1
#include <stdio.h>
errno_t fopen_s(FILE * restrict * restrict streamptr,
                const char * restrict filename,
                const char * restrict mode);

Runtime-constraints

None of streamptr, filename, or mode shall be a null pointer.

If there is a runtime-constraint violation, fopen_s does not attempt to open a file. Furthermore, if streamptr is not a null pointer, fopen_s sets *streamptr to the null pointer.

Description

The fopen_s function opens the file whose name is the string pointed to by filename, and associates a stream with it.

The mode string shall be as described for fopen, with the addition that modes starting with the character ’w’ or ’a’ may be preceded by the character ’u’, see below:

• uw truncate to zero length or create text file for writing, default permissions
• ua append; open or create text file for writing at end-of-file, default permissions
• uwb truncate to zero length or create binary file for writing, default permissions
• uab append; open or create binary file for writing at end-of-file, default permissions
• uw+ truncate to zero length or create text file for update, default permissions
• ua+ append; open or create text file for update, writing at end-of-file, default permissions
• uw+b or uwb+ truncate to zero length or create binary file for update, default permissions
• ua+b or uab+ append; open or create binary file for update, writing at end-of-file, default permissions

To the extent that the underlying system supports the concepts, files opened for writing shall be opened with exclusive (also known as non-shared) access. If the file is being created, and the first character of the mode string is not ’u’, to the extent that the underlying system supports it, the file shall have a file permission that prevents other users on the system from accessing the file. If the file is being created and first character of the mode string is ’u’, then by the time the file has been closed, it shall have the system default file access permissions¹⁰⁾.

If the file was opened successfully, then the pointer to FILE pointed to by streamptr will be set to the pointer to the object controlling the opened file. Otherwise, the pointer to FILE pointed to by streamptr will be set to a null pointer.

Returns

The fopen_s function returns zero if it opened the file. If it did not open the file or if there was a runtime-constraint violation, fopen_s returns a non-zero value.

¹⁰⁾ These are the same permissions that the file would have been created with by fopen.

Answer 6

The fopen_s() function has been added by Microsoft to the C runtime with the following fundamental differences from fopen():

• if the file is opened for writing ("w" or "a" specified in the mode) then the file is opened for exclusive (non-shared) access (if the platform supports it).
• if the "u" specifier is used in the mode argument with the "w" or "a" specifiers, then by the time the file is closed, it will have system default permissions for others users to access the file (which may be no access if that's the system default).
• if the "u" specified is not used in those cases, then when the file is closed (or before) the permissions for the file will be set such that other users will not have access to the file.

Essentially it means that files the application writes are protected from other users by default.

They did not do this to fopen() due to the likelyhood that existing code would break.

Microsoft has chosen to deprecate fopen() to encourage developers for Windows to make conscious decisions about whether the files their applications use will have loose permissions or not.

Jonathan Leffler's answer provides the proposed standardization language for fopen_s(). I added this answer hoping to make clear the rationale.