Syntax
extern int _fmode;
Header File
fcntl.h
Description
_fmode determines in which mode (text or binary) files will be
opened and translated. The value of _fmode is O_TEXT by default,
which specifies that files will be read in text mode. If _fmode
is set to O_BINARY, the files are opened and read in binary mode.
(O_TEXT and O_BINARY are defined in fcntl.h.)
Use of "_fmode" makes your code "not Standard C": neither C89 nor
C99 have _fmode. (In fact, it is "even less standard" than that;
see below.) In other words, this "default mode" stuff is an
extension to the Standard.
If you write 100% Standard C, you will not use _fmode, nor <fcntl.h>.
As a result, _fmode will *stay* O_TEXT, and you will never need
"rt" as a parameter to fopen().
If you *do* use _fmode, your code will not compile on a number of
systems, which do not *have* _fmode. (This includes most Unix-like
systems, many of which *do* have <fcntl.h>, which is not a Standard
C header but is a POSIX header. POSIX does not specify an _fmode
in <fcntl.h>, nor O_TEXT and O_BINARY for that matter. See
<
http://www.opengroup.org/onlinepubs/009695399/basedefs/fcntl.h.html>.)
So if you have a program that sets _fmode to O_BINARY, and then
uses "rt" to open its text files for reading, you can simply *remove*
the code that sets _fmode, and go back to using Standard C, and
the code will be both shorter *and* more portable.
Of course, making this change to the code may cause opening a binary
file with "r" or "w" not to work as desired, since those will also
now be opened in text mode. But why not fix the code to use "rb"
and "wb" mode strings for fopen() -- which must work on *any*
Standard C system, even the old C89 ones -- and stop using _fmode?
Then your code will work on this system that does provide _fmode,
and that other one that does not. (By "this system" I mean whichever
one Bill Reid is describing above. By "that other one" I mean
any POSIX-like system that has <fcntl.h> but not _fmode, or even
any system that supports C89 and/or C99 yet lacks <fcntl.h>
entirely.)
In other words, my advice is: "Avoid any non-Standard feature when
all it does is make your code longer and less portable. All you
have gained is that your code is less maintainable and harder to
move to a new platform. Use non-Standard features when they buy
you something that is worth the loss of portability." Extensions
that make your code less portable, with no gain in function or
maintainability, are worthless.[%]
This system's extension -- and by "this system" I again mean Bill
Reid's -- falls into this "worthless" category. Stop using it!
(By "it" I mean "the extension", not necessarily the system.
)
[% One can invent a scenario, perhaps involving a third party
library supplied only in binary form, in which one is forced to
use this particular extension. It then becomes "not worthless",
although had the system not provided the extension in the first
place, the third-party library would presumably have been coded
correctly in the first place, so that the extension would not be
required. In other words, its "worth" in this case is self-generated:
using the extension locks you into further use of the extension.]
