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
31  4496 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bill Cunningham wrote:
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.
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
empty file with read and write privileges.
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkPXncACgkQPFW+cUiIHNr6iACfZ0wkbBTvQQ Kyw/8D4kPzDARp
wjMAoIxZbrkMTAY487oUXsqHp9dEwbpz
=iUvy
-----END PGP SIGNATURE-----
On November 3, 2008 15:14, in comp.lang.c, Bill Cunningham
(no****@nspam.invalid) wrote:
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, ask yourself this...
"What would fopen("MyFile","r+") do/return if the file "MyFile" didn't
exist?
Now, ask yourself
"What would fopen("MyFile","w+") do/return if the file "MyFile" didn't
exist?
Are your two answers the same? If not, why not?
(Hint: Does the documentation say that "r+" will create the file if it
doesn't exist?)
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576 http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
"Lew Pitcher" <lp******@teksavvy.comwrote in message
news:c3**************************@TEKSAVVY.COM...
(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
On November 3, 2008 15:38, in comp.lang.c, Bill Cunningham
(no****@nspam.invalid) wrote:
>
"Lew Pitcher" <lp******@teksavvy.comwrote in message
news:c3**************************@TEKSAVVY.COM...
>(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.
OK, so you've got one difference:
With "r+", the file needs to exist for the fopen() to succeed, but
with "w+", the file does not need to exist.
And, from another post, you learned another difference:
With "r+", the newly opened file will not be truncated, but with "w+", the
file will be truncated.
So, I think that you've answered your own question of if "there a real
difference in r+ and w+".
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576 http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bill Cunningham wrote:
Too my understanding of the docs that I read on my posix system, no the
file needs to already exist.
Was there anywhere said that r+ creates file if it does not exist?
If you are not sure, you should read docs more carefully and/or just
write an example program that will show you what is the meaning of r+,
w+, etc. This is not the case that implementations are different than
specification.
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkPY4IACgkQPFW+cUiIHNpRFQCgpGU23oMfF3 bKEzb8P0mmoqpN
/MAAnifDbXcnJzDGS3EOEQNACQias8ku
=Mtwi
-----END PGP SIGNATURE-----
On Nov 3, 2:14*pm, "Bill Cunningham" <nos...@nspam.invalidwrote:
* * 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
r+ allows you to read and modify data already in the file, as well as
adding and modifying new data.
w+ discards data already in the file, and allows you to add and modify
new data.
a+ does not allow you to read or modify data already in the file, but
does allow you to add and modify new data.
If I had file that served as a database of addresses and phone
numbers, and I wanted to be able to read and edit existing records as
well as add new records, I would use r+. If I wanted to throw away
all existing records and start over with all new records, I would use w
+. If I wanted to add new records and keep the existing records
without changing them, I would use a+.
On Mon, 3 Nov 2008 15:38:05 -0500, "Bill Cunningham"
<no****@nspam.invalidwrote:
>
"Lew Pitcher" <lp******@teksavvy.comwrote in message
news:c3**************************@TEKSAVVY.COM. ..
>(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.
If you want a posix answer, ask in a posix group. If you want a C
answer, refer to C documentation since you already have K&R II.
--
Remove del for email
On Mon, 03 Nov 2008 21:26:31 +0100, Pawel Dziepak
<pd******@quarnos.orgwrote:
>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bill Cunningham wrote:
> 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.
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
Standard C does not have file handles, or any other handles. If fopen
succeeds, it will return a FILE*. But not always. Even with w+,
fopen can fail and will return NULL.
>empty file with read and write privileges.
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkPXncACgkQPFW+cUiIHNr6iACfZ0wkbBTvQ QKyw/8D4kPzDARp
wjMAoIxZbrkMTAY487oUXsqHp9dEwbpz
=iUvy
-----END PGP SIGNATURE-----
--
Remove del for email
On Nov 4, 3:38 am, "Bill Cunningham" <nos...@nspam.invalidwrote:
"Lew Pitcher" <lpitc...@teksavvy.comwrote in message
news:c3**************************@TEKSAVVY.COM...
(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
what posix is your system ?
r+ will return 0 if the file is not exist taken it will return FILE*
w+ will always return FILE*, if file exist it will be truncated to 0
just simply write the code to demonstrate it. you can see it better.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Barry Schwarz wrote:
>Standard C does not have file handles, or any other handles. If fopen
succeeds, it will return a FILE*. But not always. Even with w+,
fopen can fail and will return NULL.
According to Wikipedia [1] and other sources: struct FILE* is a file
handler.
[1] http://en.wikipedia.org/wiki/File_descriptor
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkQWJsACgkQPFW+cUiIHNqWAwCfeT9N3Sowvb P7FQTTNEjJGpHg
SQkAn1EBmiPUK3LLM8WE+WbZPJJp5epx
=lzKc
-----END PGP SIGNATURE-----
On 4 Nov, 14:13, Pawel Dziepak <pdzie...@quarnos.orgwrote:
Barry Schwarz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
could we lose the PGP stuff?
Standard C does not have file handles, or any other handles. *If fopen
succeeds, it will return a FILE*. *But not always. *Even with w+,
fopen can fail and will return NULL.
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
[1]http://en.wikipedia.org/wiki/File_descriptor
--
Nick Keighley
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nick Keighley worte:
ITYM "handle". Despite what wikipedia says this is not standard C
terminology
Of course, "handle".
7.19.5.3/8:
"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".
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkQXkUACgkQPFW+cUiIHNr81QCfYlAOfvMsQz FMAQ/9V6C4Aq3a
ZJAAoJFxGFzRUCCe6SGoWtJbESWDOH3L
=WmWa
-----END PGP SIGNATURE-----
Pawel Dziepak wrote:
"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".
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.
Perhaps we should go to the other extreme and call it a "pedal";
I suspect I'll not be allowed to sustain that.
(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.)
--
'Don't be afraid: /Electra City/
there will be minimal destruction.' - Panic Room
Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris Dollin wrote:
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.
Ok, I see your point and, now, I agree. I think that will end that part
of discussion.
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkQZsMACgkQPFW+cUiIHNrBdQCfZMTIPP+CL/X0z0xsGxNIYVNy
oNMAnj/zxaFVC0NVHU8bItbWwcwttMqN
=VsgU
-----END PGP SIGNATURE-----
On 4 Nov, 15:05, Chris Dollin <chris.dol...@hp.comwrote:
(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.)
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.
--
Nick Keighley
Pawel Dziepak wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nick Keighley worte:
>ITYM "handle". Despite what wikipedia says this is not standard C
terminology
Of course, "handle".
7.19.5.3/8:
"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".
Let's call it a "potato masher," shall we? Or would "coddled
egg" capture the essence better?
"When I use a word it means just what I choose it to mean --
neither more nor less. The question is which is to be master --
that's all." -- H.D.
It is true that we invent our own words, and it matters not a
whit whether we call a thing a pointer, a handle, a coddled egg, or
glory. That is, it mattered not, past tense, because communication
with a set of arbitrary symbols relies on agreement about what those
symbols mean and how they are to be used. Start saying that fopen()
returns a "nice knock-down argument" and you may amuse yourself, but
you will not communicate well.
"Nobody beezifies me.
Nobody febbin ud.
Kibblezy deen voo nizee!
I hate being misunderstood." -- S.B.
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.
-- Er*********@sun.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nick Keighley wrote:
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.
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.
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkQcCYACgkQPFW+cUiIHNob6gCfRY9zoJSam4 mTEbfjlpIwl0rv
pyQAn17Cs/Bk6QQ5fvLIGsh7vf63aKQo
=xItn
-----END PGP SIGNATURE-----
Pawel Dziepak wrote:
Nick Keighley wrote:
>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.
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.
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.
(Planets, now, /those/ are the right kind of target.)
--
'Don't be afraid: /Electra City/
there will be minimal destruction.' - Panic Room
Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Sosman wrote:
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.
I don't think that I really see that difference between handle and
object that controls the stream and stores all needed information.
(I know that, I confused FILE with pointer to FILE but in my next posts
I corrected myself.)
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkQcdwACgkQPFW+cUiIHNrtUgCeLR91PVPXOf 841TLWcZwggYj8
jZgAnR8qY3hY3gQhKb3K+CytN5uI9v09
=wmEQ
-----END PGP SIGNATURE-----
Chris Dollin wrote:
....
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.
I've seen people do that (with a reflector). When you've got enough
sunlight to make it work, there's nothing silly about it - it saves
fuel and doesn't pollute the environment. That makes it poor measure
of silliness.
Nick Keighley writes:
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
If that was it, said power was doubly confused.
"#define getc(x) fgetc(x)" or even "#define getc(x) getc(x)"
would satisfy such a requirement. However:
C99 7.19.7.5 The getc function:
The getc function is equivalent to fgetc, except that if it is
implemented as a macro, it may evaluate stream more than once, so
the argument should never be an expression with side effects.
C89 has the same paragraph.
and (if I recall correctly)
the wording of The Standard almost forced it to be a struct.
The wording of something else in it, perhaps. There are a lot of words
there:-)
--
Hallvard
jameskuyper wrote:
Chris Dollin wrote:
...
>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.
I've seen people do that (with a reflector). When you've got enough
sunlight to make it work, there's nothing silly about it - it saves
fuel and doesn't pollute the environment. That makes it poor measure
of silliness.
No, James, a /sunbeam/. When you (or the Galactic Patrol on your behalf)
concentrates the whole radiant output of the sun into a single beam.
I should have been a little more hintful.
--
'Don't be afraid: /Electra City/
there will be minimal destruction.' - Panic Room
Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN
Pawel Dziepak wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Sosman wrote:
> 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.
I don't think that I really see that difference between handle and
object that controls the stream and stores all needed information.
I'm not very familiar with the Windows API's, but it's my belief
that they use the term "handle" for various constructs that manage
files, processes, threads, and whatnot. Is Windows' "file handle"
the same thing as a FILE* or FILE, or does a FILE have a "file handle"
(or reference to same) buried somewhere within it? If the latter (and
again I confess unfamiliarity with the API's), then using the word
"handle" for two different things would be confusing, especially if
one sort of "handle" contains an instance of or reference to the other.
Synecdoche: Just Say No.
-- Er*********@sun.com
Nick Keighley <ni******************@hotmail.comwrites:
On 4 Nov, 15:05, Chris Dollin <chris.dol...@hp.comwrote:
>(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.)
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.
I don't see what that would have to do with it. Even if getc has to be
implemented as a macro, there's no reason that macro can't *call* a
function.
int fgetc(FILE *f) { ... }
int getc(FILE *f) { return fgetc(f); }
#define getc(f) fgetc(f)
I can think of a couple ways to implement stdio where FILE is not a
struct, though granted they are a bit silly.
- On a POSIX-like system, FILE could be an int containing the file
descriptor. getc/putc call read() and write() with a single
character; no buffering is done. fflush() and setvbuf() are no-ops.
- FILE could itself be a pointer to the "real" file object, or an index
into an array of such objects.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Sosman wrote:
I'm not very familiar with the Windows API's, but it's my belief
that they use the term "handle" for various constructs that manage
files, processes, threads, and whatnot. Is Windows' "file handle"
the same thing as a FILE* or FILE, or does a FILE have a "file handle"
(or reference to same) buried somewhere within it? If the latter (and
again I confess unfamiliarity with the API's), then using the word
"handle" for two different things would be confusing, especially if
one sort of "handle" contains an instance of or reference to the other.
WinAPI has its own functions to manage files. However that's how MSDN
describes handles [1]:
"An application cannot directly access object data or the system
resource that an object represents. Instead, an application must obtain
an object handle, which it can use to examine or modify the system
resource. Each handle has an entry in an internally maintained table.
These entries contain the addresses of the resources and the means to
identify the resource type."
Which perfectly fits FILE definition with one exception, standard don't
mention that each FILE structure/whatever has an entry in an internal table.
However, we know that FILE consist of some kind of file descriptor (in
posix systems it will be just an integer) that is stored in an internal
table, that allows system to associate FILE with file on disk.
Concluding, FILE and handles seems to be very similar and that's why I
think that its not wrong to call FILE "a file handle". On the other
hand, it may be confusing, what that discussion showed very well.
[1] http://msdn.microsoft.com/en-us/library/ms724457.aspx
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkQgdcACgkQPFW+cUiIHNo26gCdGqlBD3r5KV FFDqfAm7aHkmEK
+zsAnik2/Loe1vvY1Sy14Wc8oDxtESLi
=J4aa
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nate Eldredge wrote:
I can think of a couple ways to implement stdio where FILE is not a
struct, though granted they are a bit silly.
- On a POSIX-like system, FILE could be an int containing the file
descriptor. getc/putc call read() and write() with a single
character; no buffering is done. fflush() and setvbuf() are no-ops.
- FILE could itself be a pointer to the "real" file object, or an index
into an array of such objects.
Ok, I didn't realize that situations. However, in that cases FILE is
some kind of pointer (maybe not exactly in the C standard meaning) to
structure.
That's why we can say that FILE is either a structure or a pointer to
structure.
Pawel Dziepak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkkQgusACgkQPFW+cUiIHNqgAACfQyZyUhyJBu rrTPiAJC7o25Qf
QioAoI63HO8/ANJvbPYz9jRQusTNWx0e
=sd8S
-----END PGP SIGNATURE-----
Nate Eldredge <na**@vulcan.lanwrites:
[...]
I can think of a couple ways to implement stdio where FILE is not a
struct, though granted they are a bit silly.
- On a POSIX-like system, FILE could be an int containing the file
descriptor. getc/putc call read() and write() with a single
character; no buffering is done. fflush() and setvbuf() are no-ops.
- FILE could itself be a pointer to the "real" file object, or an index
into an array of such objects.
FILE could be an array of unsigned char, with the standard functions
and macros converting between FILE* and, say, __HIDDEN_FILE* to access
the information. The point would be to make it just a little bit more
difficult to write code that depends on the internals of FILE.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Barry Schwarz" <sc******@dqel.comwrote in message
news:sv********************************@4ax.com...
Standard C does not have file handles, or any other handles. If fopen
succeeds, it will return a FILE*. But not always. Even with w+,
fopen can fail and will return NULL.
I was just going to say in posix "b" has no meaning. But what about the
C standard? For maximal portability should a "b" be included in the code for
other systems like unixes and win32(64) ?
Bill
On November 4, 2008 16:08, in comp.lang.c, Bill Cunningham
(no****@nspam.invalid) wrote:
>
"Barry Schwarz" <sc******@dqel.comwrote in message
news:sv********************************@4ax.com...
>Standard C does not have file handles, or any other handles. If fopen
succeeds, it will return a FILE*. But not always. Even with w+,
fopen can fail and will return NULL.
I was just going to say in posix "b" has no meaning. But what about
the
C standard? For maximal portability should a "b" be included in the code
for other systems like unixes and win32(64) ?
Yes, for maximum portability, if your code expects a FILE * to carry binary
values, it should fopen() it with the "b" option. This ensures that, under
all platforms, the appropriate data interpretation/transformation takes
place. (Platforms that do not handle text differently from binary, such as
POSIX, Unix and Linux platforms, will do nothing special when you fopen()
with the "b" mode. However, platforms that *do* handle text different from
binary *will* properly handle non-textual data when you use the "b" mode.)
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576 http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Nick Keighley wrote:
Chris Dollin <chris.dol...@hp.comwrote:
>(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.)
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.
No, getc is _permitted_ to be a macro, and even a macro that
evaluates its parameter more than once (thus making it unusable
with parameters having side effects). It may also be a function,
in which case it will be identical with fgetc. However a macro can
result in significant efficiency improvements for i/o, which is why
all this is allowed. The same applies to putc.
i.e. the following is NOT valid C code:
FILE *fa[COUNT]; /* array of FILE* pointers */
...
ch = getc(*fa++);
but
ch = getc(stdin);
is just fine.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer <cb********@yahoo.comwrites:
No, getc is _permitted_ to be a macro, and even a macro that
evaluates its parameter more than once (thus making it unusable with
parameters having side effects). It may also be a function, in
which case it will be identical with fgetc. However a macro can
result in significant efficiency improvements for i/o, which is why
all this is allowed. The same applies to putc.
This permitted/required distinction seems to be overlooked by many
commentators. AIUI, getc() is also permitted to NOT be implemented as
a macro, i.e. a conforming implementation could have
#include <stdio.h>
int main(void) {
#ifdef getc
puts("yes");
#else
puts("no");
#endif
return 0;
}
produce "no" as output.
i.e. the following is NOT valid C code:
but not for any reason related to the preceding paragraph in your
post.
FILE *fa[COUNT]; /* array of FILE* pointers */
...
ch = getc(*fa++);
Incrementing an array, Chuck. Come on.
I think
FILE *fa[COUNT], **fpp = fa;
ch = getc(*fpp++);/* potential UB due to multi-eval of macro arg */
more closely illustrates the point I think you tried to make.
but
ch = getc(stdin);
is just fine.
Indeed.
mlp This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: bird |
last post by:
What can cause the PHP code fopen("filename","a") to fail with
permission denied message as below?
------------------
Warning: fopen(filename): failed to open stream: Permission denied in...
|
by: mkoleno346 |
last post by:
If I want to change autentication modes for an instance of MSDE that I
already installed, what is the best way to go about this? I don't
think you can change authentication modes using any of the...
|
by: Dave O'Hearn |
last post by:
I want to open a file for both reading and writing, but when I do
"ios::in|ios::out" with an fstream, it creates the file if it doesn't
already exist. I don't like that last part. C's fopen has the...
|
by: uremae |
last post by:
I tried to open some large files in my computer. (ram 512MB)
1. is there limitation of file size FOPEN?
2. if I have a file that is larger than the maximum size, how can I
open the file?
|
by: Gaurav Vaish |
last post by:
Hi,
How can I accomplish multiple authentication modes in one application?
I have the following scenario:
- A company, X, has some employees
- Those on rolls have an AD account
- Those...
|
by: Jacek Dziedzic |
last post by:
Hi!
I often find that my programs need to store information on
"current mode of something" with two or at most several
mutually exclusive "modes" to choose from, e.g.
- datafile: is it in a)...
|
by: rfhurley |
last post by:
I'm a newbie at this... I'm trying to run a PHP script from the W3C PHP
tutorial, and the example shows the following code:
<html>
<body>
<?php
$file=fopen("welcome.txt","r");
?>
|
by: Rebeus87 |
last post by:
Hi i am new to Perl and i was wondering if you could look at my scripts and give me advice and feedback on how i could improve my scripts.
I am using /etc/fb.modes to write Perl scripts.
...
|
by: cscorley |
last post by:
For some reason, I cannot use fopen() on the file in write mode. The
file "time" is in the same directory as the .php file, with
permissions set to 0766.
PHP Version 5.2.5
Apache/2.2.8
code...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
