The C Standard identifies specific strings to use for the
mode on calls to
fopen_s(). C11 provides a new mode flag,
x, that provides the mechanism needed to determine if the file that is to be opened exists. To be strictly conforming and portable, one of the strings from the following table (adapted from the C Standard, subclause 18.104.22.168 [ISO/IEC 9899:2011]) must be used:
Strings to Use for the Mode on Calls to
Open text file for reading
Truncate to zero length or create text file for writing
Create text file for writing
Append; open or create text file for writing at end-of-file
Open binary file for reading
Truncate to zero length or create binary file for writing
Create binary file for writing
Append; open or create binary file for writing at end-of-file
Open text file for update (reading and writing)
Truncate to zero length or create text file for update
Create text file for update
Append; open or create text file for update, writing at end-of-file
Open binary file for update (reading and writing)
Truncate to zero length or create binary file for update
Create binary file for update
Append; open or create binary file for update, writing at end-of-file
mode string begins with one of these sequences, the implementation might choose to ignore the remaining characters, or it might use them to select different kinds of files.
fopen_s(), any of the mode strings used for writing (
a) may be prefixed with the
u character to give the file system default access permissions.
An implementation may define additional
mode strings, but only the modes shown in the table are fully portable and C compliant. Beware that Microsoft Visual Studio 2012 and earlier do not support the
u mode characters [MSDN].
mode string that is not recognized by an implementation may cause the call to
fopen() to fail.
|LDRA tool suite|
|Polyspace Bug Finder|
|CERT C: Rec. FIO11-C|
Checks for bad file access mode or status (rec. fully covered)
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
|[ISO/IEC 9899:2011]||Subclause 22.214.171.124, "The |
Someone mentioned a GNU C Library extension with the letter 'x' for the O_EXCL flag in a comment in a previous item.
Another previous item mentioned the letter 'u' as modifying the permissions on files - possibly in conjunction with fopen_s().
These seem somewhat inconsistent with the advice given here.
Douglas A. Gwyn
The point is that using anything beyond this list is nonportable, which might be okay but the programmer needs to consider whether it fits the project goals, and should warn loudly about it in his source code.
Section 7.19.3 of C99 says
How does this reconcile with the definition of the flags given above? Is this a problem with the standard?
There is no "problem" in the standard. The idea is that by opening something in append mode, you will only be appending to it. Therefore, the point of having a file position indicator (knowing where you are in a file and being able to move around within a file) is unnecessary and, in fact, possibly dangerous (what validity is there in seeking around on something that is by definition append-only?).
If you carefully read the definitions of all of the output functions, you can notice that the C standard weaves around these problems by making the file position indicator basically useless on an append stream, e.g.:
ok... shaun and I talked about this... looks the file position indicator isn't defined to do anything useful and has no meaning whatsoever in append mode since you can't seek
I recently had this same question.
> 1. append mode
> section 7.19.3 Files paragraph 1 states:
> If a file can support positioning requests (such as a
> disk file, as opposed to a terminal), then a file position indicator associated with the
> stream is positioned at the start (character number zero) of the file, unless the file is
> opened with append mode in which case it is implementation-defined whether the file
> position indicator is initially positioned at the beginning or the end of the file.
> while section 126.96.36.199 The fopen function, paragraph 3 seemingly contradicts this:
> a append; open or create text file for writing at end-of-file
> i'm guessing section section 7.19.3 is correct and that section 188.8.131.52 is simply a misleading simplification, yes?
I don't see any obvious contradiction.
The first part describes the initial location of the
"file position indicator" when a file is opened with
append, the second says that writes always occur at
the end of the file.
They are separate things. The first, in effect, says
that what you get returned from ftell() just after
opening with append is implementation defined. The
second says how opening with append differs from a
regular opened-for-writing file.
This recommendation could use a noncompliant code example and compliant solution.