Hi, there,
After you call fopen with "ba+", use ftell to see where you are.
Don't forget Buckaroo Bonzai's "Wherever you go, there you are."
With modern file systems, there is a potential bug in fseek/ftell.
12.25: What's the difference between fgetpos/fsetpos and ftell/fseek?
What are fgetpos() and fsetpos() good for?
A: ftell() and fseek() use type long int to represent offsets
(positions) in a file, and may therefore be limited to offsets
of about 2 billion (2**31-1). The newer fgetpos() and fsetpos()
functions, on the other hand, use a special typedef, fpos_t, to
represent the offsets. The type behind this typedef, if chosen
appropriately, can represent arbitrarily large offsets, so
fgetpos() and fsetpos() can be used with arbitrarily huge files.
fgetpos() and fsetpos() also record the state associated with
multibyte streams. See also question 1.4.
References: K&R2 Sec. B1.6 p. 248; ISO Sec. 7.9.1,
Secs. 7.9.9.1,7.9.9.3; H&S Sec. 15.5 p. 252.
And speaking of "can I tell if a file exists..." we have this:
19.11: How can I check whether a file exists? I want to warn the user
if a requested input file is missing.
A: It's surprisingly difficult to make this determination reliably
and portably. Any test you make can be invalidated if the file
is created or deleted (i.e. by some other process) between the
time you make the test and the time you try to open the file.
Three possible test functions are stat(), access(), and fopen().
(To make an approximate test using fopen(), just open for
reading and close immediately, although failure does not
necessarily indicate nonexistence.) Of these, only fopen() is
widely portable, and access(), where it exists, must be used
carefully if the program uses the Unix set-UID feature.
Rather than trying to predict in advance whether an operation
such as opening a file will succeed, it's often better to try
it, check the return value, and complain if it fails.
(Obviously, this approach won't work if you're trying to avoid
overwriting an existing file, unless you've got something like
the O_EXCL file opening option available, which does just what
you want in this case.)
References: PCS Sec. 12 pp. 189,213; POSIX Sec. 5.3.1,
Sec. 5.6.2, Sec. 5.6.3.
Let's not forget that fopen() and stat() can also fail for permission
reasons (and others for sure, which I can't think of right now, but
which are probably pertinant).
Isn't anybody going to tell the poor suffering OP about his escaped t
that looks a bit like a backslash and a 't' but isn't? OK, I will.
No, I'll let the FAQ do it:
19.17: Why can't I open a file by its explicit path? The call
fopen("c:\newdir\file.dat", "r")
is failing.
A: The file you actually requested -- with the characters \n and \f
in its name -- probably doesn't exist, and isn't what you
thought you were trying to open.
In character constants and string literals, the backslash \ is
an escape character, giving special meaning to the character
following it. In order for literal backslashes in a pathname to
be passed through to fopen() (or any other function) correctly,
they have to be doubled, so that the first backslash in each
pair quotes the second one:
fopen("c:\\newdir\\file.dat", "r")
Alternatively, under MS-DOS, it turns out that forward slashes
are also accepted as directory separators, so you could use
fopen("c:/newdir/file.dat", "r")
(Note, by the way, that header file names mentioned in
preprocessor #include directives are *not* string literals, so
you may not have to worry about backslashes there.)
No wonder so many people are saying things like "Read the FAQ!" and
"FAQ for president!" and stuff like that.