Bill said:Is there a real difference in r+ and w+ ? I read in my man pages that r+
opened a file for reading and writing while w+ opened a file for reading and
writing and if the file didn't exist it would by created. If it existed it
would be truncated.
Is there a real difference in r+ and w+ ? I read in my man pages that
r+
opened a file for reading and writing while w+ opened a file for reading
and writing and if the file didn't exist it would by created. If it
existed it would be truncated.
(Hint: Does the documentation say that "r+" will create the file if it
doesn't exist?)
Too my understanding of the docs that I read on my posix system, no
the
file needs to already exist.
Bill said:Too my understanding of the docs that I read on my posix system, no the
file needs to already exist.
Is there a real difference in r+ and w+ ? I read in my man pages that r+
opened a file for reading and writing while w+ opened a file for reading and
writing and if the file didn't exist it would by created. If it existed it
would be truncated.
Bill
Too my understanding of the docs that I read on my posix system, no the
file needs to already exist.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
That's the difference. r+ doesn't truncate the file, it just opens it
and allows to read and write. fopen with w+ always returns a handle to
Too my understanding of the docs that I read on my posix system, no the
file needs to already exist.
Bill
Barry Schwarz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
According to Wikipedia [1] and other sources: struct FILE* is a file
handler.
ITYM "handle". Despite what wikipedia says this is not standard C
terminology
Pawel said:"The fopen function returns a pointer to the object controlling the stream."
C99 doesn't says that fopen returns a handle. However, there is no "file
handle" definition in the standard, so why don't call that "object
controlling the stream" a handle? I know that there is no clear
definition what a file handle is, but that doesn't mean that structure
FILE mustn't be called "a handle".
Chris said:Since /other/ things are called "file handles", and "a FILE*" is a way
to refer to a FILE* value, then calling a FILE* value a "file handle"
induces more confusion than is perhaps necessary.
(Do we know that FILE is a struct at all? Clearly it's /likely/, even
/sensible/, to be a struct, but a hasty scan of a draft to hand didn't
actually commit.)
Nick said:I tried arguing once that FILE didn't have to be a struct. But one
of the Powers (I *think* Chris Torek) pointed out that it would be
difficult (I paraphrase) for it not to be a struct. He pointed
out that some of the low level calls (eg. getc) are required to be
implemented as both a macro and a function and (if I recall correctly)
the wording of The Standard almost forced it to be a struct.
Pawel said:7.19.1/2:
"(...) FILE which is an object type capable of recording all the
information needed to control a stream, (...)"
That doesn't *directly* say that FILE is a structure, but I don't think
that there is any other implementation, that's not just proof of concept.
Eric said:Using "handle" to describe what fopen() returns is particularly
bad, because "handle" has already been assigned a meaning -- worse,
it has been assigned a meaning that is related to, but different from,
"pointer to a FILE object." Using "handle" is therefore worse than
using "kibblezy" because it invites, even encourages, confusion.
There's a difference between "it would be daft for FILE not to be a struct"
and "the standard requires FILE to be a struct".
A proof-of-concept implementation would be sufficient as a counter-example
to "FILE is a struct", even if we all agreed that such an implementation
would be sillier than frying eggs with a sunbeam.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.