"P.J. Plauger" <pjp@dinkumware.com> writes:

[...]

> >                                             I could possibly see how
> > it could be declared (which it isn't) that when one can't open a file
> > one shall be at the end of it automatically, but a file that doesn't
> > even exist?
>
> You are clearly thinking like a native English speaker, not a programmer.

Not necessarily. A programmer wouldn't consider

  char const* p1 = ""; // points to empty string

and

  char const* p2 = 0; // points to no string

to be equivalent. For one point, using it in a call to the function

  bool end_of_string(char const* p) { return !*p; }

is well-defined (and returns true) for p1, but is undefined behaviour
for p2 (and the same is true for using the pointer with the
std::strxxx functions).

After all, there's a difference between "does not exist" and "does
exist and has length zero".

Now that doesn't mean the standard is in error. AFAICT, EOF is not
really defined as "end of file". Assume you are doing a read from a
remote file, and in the middle of the read the network goes down. The
read will not be able to get any more characters from the file, and
therefore the defined behaviour of read is to set eof (and, of course,
fail). Now by any common sense we did not get to the end of the file -
we just were not able to get any more characters from it. And that's
obviously the meaning of EOF, as defined in the standard: "Trying to
get more characters failed". Which in most cases happens at the end of
file, but certainly may happen also in other circumstances (such as,
there is no file after all).

[...]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<3d07df54$0$6213$4c41069e@reader0.ash.ops.us.uu.net>...
> "Tommy McDaniel" <tdmj@hotmail.com> wrote in message
> news:c0fba064.0206121010.5f3a5f47@posting.google.com...
>
> > > > > Now, I am aware that using ios::binary as an openmode will result in
> > > > > the file not being opened.
> > >
> > > If it doesn't exist, you mean. Otherwise, it should open just fine, with
> > > read and write permissions, IIRC.
> >
> > No, I meant what I stated, although looking back I may have stated it
> > ambiguously. I meant if the entire openmode was just ios::binary. I
> > also believed until recently that such a thing would result in the
> > file being opened for reading and writing, but the problem I was
> > having that originated all this only manifested itself when using only
> > ios::binary for an openmode. It was pointed out to me in comp.lang.c++
> > that using only ios::binary was illegal (which really surprised me
> > because the book I have gives explicit examples of using only
> > ios::binary and then being able to input and output, and I seemed to
> > remember doing it previously at some point in time on some computer or
> > other), and when I searched in the Standard, sure enough, there was
> > 27.8.1.3, which says that if the openmode isn't in the provided table
> > the file won't be opened, and ios::binary alone isn't in the table.
> > There could be something else in the Standard that changes that, since
> > I am not an expert here, but if there is I don't know about it.
>
> It is indeed true that ios::binary is not a permissible open mode.
> Some constructors, such as basic_ifstream(const char *, ios::openmode),
> provide implicit additional mode bits that rescue a bald ios::binary.
> But the case you cite has no such implicit bits. I stand corrected.
>
> > > > > And that's it. Now the way I see it, 1 obviously doesn't apply.
> > > > > Leaving 2. However, the wording says "end-of-file occurs." Can one
> > > > > really reach the end of a file that can't be read to start with?
> > >
> > > Sure can. Right out of the starting gate.
> >
> > Having thought a little about this since I read that, it occurs to me
> > that, in my opinion, such a thing may be true in some cases but not
> > others. If one takes an expression that goes "end-of-<word>", where
> > <word> is a verb, it seems to me that one can usually reach the end at
> > any point. But if <word> is a noun, it doesn't seem the same to me in
> > all circumstances. Consider "end-of-cord". One can't reach the end of
> > the cord at the beginning unless one starts there.
>
> Or the cord has zero length, which is the same thing.
>
> >                                                   Taking the analogy
> > to files, one would be at the end of the file from the very beginning
> > only if one explicitly started at that particular point.
>
> Or the file had zero length, which is the same thing.
>
> >                                                        But the
> > Standard, that I know of, doesn't specify such a thing on open()
> > errors.
>
> Nor does it specify a lot of such corner cases, unless they happen
> to be (regrettable) exceptions to a general rule.
>
> >        Also, consider if the file doesn't even exist. How can one be
> > at the end of a file that doesn't even exist?
>
> Because that's where you began?
>
> >                                             I could possibly see how
> > it could be declared (which it isn't) that when one can't open a file
> > one shall be at the end of it automatically, but a file that doesn't
> > even exist?
>
> You are clearly thinking like a native English speaker, not a programmer.
> English is full of special constructs that distinguish zero, one, and
> more than one. Good testing and looping code is robust enough to take
> all these possibilities in stride, ideally with no special-case code.
> The C++ Standard is chock full of constructs that survive zero-ness,
> one-ness, and many-ness with equal ease.
>
> > > >              Unfortunately, read() only mentions reaching end-of-file.
> > > > > Is the possibility illustrated by my sample code above, of trying to
> > > > > read from a file that can't be read, either not covered by the
> > > > > Standard, covered ambiguously by option 2 above, or covered elsewhere
> > > > > in the Standard?
> > >
> > > The middle one.
> >
> > If it is in fact covered ambiguously by the statement "end-of-file",
> > doesn't this pretty much rise to the level of an error?
>
> Well, yes, but. The C++ Standard is also chock full of downright erroneous
> and/or inconsistent statements. The C++ committee has so far spent most
> of its time dealing with these. If you think the problem is severe
> enough, then write up a Defect Report, preferably with suggested wording
> changes to fix the problem. If you post it here, one of the moderators
> will likely submit it to the committee on your behalf. Eventually, it
> will get committee time and a resolution of some sort.
>
> >                                                        Some people
> > may interpret "end-of-file" to include when a file can't be opened,
> > but I don't know that that is a universal interpretation of that
> > expression.
>
> As a general rule, an open failure is signaled through a different
> channel than merely reporting an instant end-of-file. But if you
> ignore that channel and get an instant end-of-file when you try to
> read the stream, I consider that pretty reasonable behavior.
>
> >         I certainly don't see it that way, meaning that there are
> > probably plenty of other people that see it the same way, not that I
> > know.
>
> Very likely, FWIW. The C++ Standard is not intended to be a tutorial
> document, however.
>
> > > >                    Does the Standard define 'end-of-file occurring'
> > > > > somewhere I don't know about? If it is covered as-is by option 2, I
> > > > > find that extremely ambiguous, or just plain wrong (how many
> > > > > end-of-book's have you gotten to when you couldn't read the book to
> > > > > start with?).
> > >
> > > Happens to me all the time, particularly when I'm too busy to open the
> > > book. Or the book wasn't where I hoped to find it. Or...
> >
> > Do you really consider yourself to have gotten to the end of those
> > books?
>
> Yes.
>
> >       In that case, I've gotten to the end of a lot more things than
> > I knew. Like most books ever published.
>
> So you have.
>
> >                                        In my mind, not starting
> > something isn't equal to reaching the end of it. If not, then I
> > proudly declare that I am done with my 99.9999% compliant C++
> > compiler, my absolutely greatest OS in the world, and a lot of other
> > things.
>
> Congratulations. Zero-length strings are indeed so ubiquitous that
> they help you concoct all sorts of farcical conclusions. But that
> doesn't diminish their utility in many more serious contexts.
>
> > > None of the above. The C++ Standard is not always worded as precisely,
> > > or as clearly, as we all would want. And you are not stupid for having
> > > trouble reading it as a tutorial document. We all share such trouble,
> > > from time to time.
> >
> > Indeed, the C++ Standard is not perfect. But if this is a particular
> > example of something that could be improved or flat-out fixed
> > (depending on your mindset and interpretation of the term
> > "end-of-file"), shouldn't it be done, so that everyone sane reading
> > the new and improved version can come to the same conclusion?
>
> Sure it should be done, if you can find the energy to whomp up a DR,
> and if a moderator is convinced to submit it, and if the committee
> can find time to process it in the near future, etc. The work on a
> committee of volunteers gets done by people who volunteer to do the
> work.
>
> >                                                              I can't
> > discount the possibility that I'm the only person that interprets the
> > expression "end-of-file" the way that I do, but in all likelihood
> > there are others (including some of those who know a lot more about
> > C++ than me). I could say "bring me a hammer", and by that also mean
> > bring me a nail, a screwdriver, wash the car, and paint the house, but
> > few would disagree that my language for expressing that is ambiguous
> > to the point of being incorrect, at least to express what I mean.
>
> Some would even say that it's downright wrong, since it's not likely
> you'll find anybody acculturated to share that meaning with you.
> The wording at issue here is not so clear cut, however.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com
>
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sorry for taking three eternities to respond to all that. In case it's
been so long you can't remember what we were talking about, we were
talking about how the description of basic_istream::read() is
ambiguous about what to do when one tries to read from a file that
couldn't be opened. You mentioned me writing up a Defect Report, and I
would be happy to do so, but how does one go about doing such a thing,
and then submitting it? I would think that just adding a few words to
make the description of read() more like that of write(), which
explicitly mentions the possibility of errors, should do it. As I
said, I would be happy to do whatever I could, but I just need to know
what procedures and such I am supposed to follow.

                                                  Tommy McDaniel


======================================= MODERATOR'S COMMENT:
 Please don't overquote.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"P.J. Plauger" <pjp@dinkumware.com> wrote in message news:<3cff7295$0$1790$4c41069e@reader0.ash.ops.us.uu.net>...
> "Tommy McDaniel" <tdmj@hotmail.com> wrote in message
> news:c0fba064.0206042356.2a85744b@posting.google.com...
>
> > tdmj@hotmail.com (Tommy McDaniel) wrote in message
>  news:<c0fba064.0205310157.68adbb9d@posting.google.com>...
> > > I asked the following in comp.lang.c++ a couple of times, and since no
> > > one responded I assume that the question is either really stupid or
> > > really hard. Consider the following code:
> > >
> > > #include <fstream>
> > > ...
> > > int main()
> > > {
> > >    fstream file("my_file", ios::binary);
> > >    int temp;
> > >
> > >    file.read(reinterpret_cast<char *>(&temp), sizeof(temp));
> > > ...
> > > }
> > >
> > > Now, I am aware that using ios::binary as an openmode will result in
> > > the file not being opened.
>
> If it doesn't exist, you mean. Otherwise, it should open just fine, with
> read and write permissions, IIRC.

No, I meant what I stated, although looking back I may have stated it
ambiguously. I meant if the entire openmode was just ios::binary. I
also believed until recently that such a thing would result in the
file being opened for reading and writing, but the problem I was
having that originated all this only manifested itself when using only
ios::binary for an openmode. It was pointed out to me in comp.lang.c++
that using only ios::binary was illegal (which really surprised me
because the book I have gives explicit examples of using only
ios::binary and then being able to input and output, and I seemed to
remember doing it previously at some point in time on some computer or
other), and when I searched in the Standard, sure enough, there was
27.8.1.3, which says that if the openmode isn't in the provided table
the file won't be opened, and ios::binary alone isn't in the table.
There could be something else in the Standard that changes that, since
I am not an expert here, but if there is I don't know about it.

> >                             However, I do not understand why the code
> > > results in eofbit being set for file. According to section 27.6.1.3 of
> > > the Standard, under the description of read(), it first mentions what
> > > to do if !good(). Since the brand new stream is in fact good, we read
> > > on. It then gives the two conditions under which extraction stops:
> > >
> > > 1. n characters are stored.
> > > 2. end-of-file occurs on the input sequence (in which case the
> > > function calls setstate(failbit|eofbit), which may throw
> > > ios_base::failure).
> > >
> > > And that's it. Now the way I see it, 1 obviously doesn't apply.
> > > Leaving 2. However, the wording says "end-of-file occurs." Can one
> > > really reach the end of a file that can't be read to start with?
>
> Sure can. Right out of the starting gate.

Having thought a little about this since I read that, it occurs to me
that, in my opinion, such a thing may be true in some cases but not
others. If one takes an expression that goes "end-of-<word>", where
<word> is a verb, it seems to me that one can usually reach the end at
any point. But if <word> is a noun, it doesn't seem the same to me in
all circumstances. Consider "end-of-cord". One can't reach the end of
the cord at the beginning unless one starts there. Taking the analogy
to files, one would be at the end of the file from the very beginning
only if one explicitly started at that particular point. But the
Standard, that I know of, doesn't specify such a thing on open()
errors. Also, consider if the file doesn't even exist. How can one be
at the end of a file that doesn't even exist? I could possibly see how
it could be declared (which it isn't) that when one can't open a file
one shall be at the end of it automatically, but a file that doesn't
even exist?

> >                                                                   There
> > > is no such ambiguity in the description of write(), which gives an
> > > ending condition of "inserting in the output sequence fails"
> > > (27.6.2.6).
>
> Writing and reading are fundamentally asymmetrical. The former generates
> and disposes, while the latter attempts to consume and parse. They thus
> have different failure modes.

Indeed so. I was merely highlighting the wording used in the other
side of the assymetry.

> >              Unfortunately, read() only mentions reaching end-of-file.
> > > Is the possibility illustrated by my sample code above, of trying to
> > > read from a file that can't be read, either not covered by the
> > > Standard, covered ambiguously by option 2 above, or covered elsewhere
> > > in the Standard?
>
> The middle one.

If it is in fact covered ambiguously by the statement "end-of-file",
doesn't this pretty much rise to the level of an error? Some people
may interpret "end-of-file" to include when a file can't be opened,
but I don't know that that is a universal interpretation of that
expression. I certainly don't see it that way, meaning that there are
probably plenty of other people that see it the same way, not that I
know.

> >                    Does the Standard define 'end-of-file occurring'
> > > somewhere I don't know about? If it is covered as-is by option 2, I
> > > find that extremely ambiguous, or just plain wrong (how many
> > > end-of-book's have you gotten to when you couldn't read the book to
> > > start with?).
>
> Happens to me all the time, particularly when I'm too busy to open the
> book. Or the book wasn't where I hoped to find it. Or...

Do you really consider yourself to have gotten to the end of those
books? In that case, I've gotten to the end of a lot more things than
I knew. Like most books ever published. In my mind, not starting
something isn't equal to reaching the end of it. If not, then I
proudly declare that I am done with my 99.9999% compliant C++
compiler, my absolutely greatest OS in the world, and a lot of other
things.

> >              Actually, this problem would seem to creep up any time
> > > you try to read from a stream that can't be read from yet still has
> > > goodbit set, which the above is just an example of.
>
> Yes.
>
> > Anyone? Surely there's someone out there that either has an opinion on
> > this or doesn't have an opinion on this. Beyond curing my paranoia, if
> > it is in fact a defect then it is something that should be recognized
> > as such so that it can be fixed whenever the Standard is updated. And
> > if I'm just a moron and it's not a defect in one way or another, that
> > can be good to know too.
>
> None of the above. The C++ Standard is not always worded as precisely,
> or as clearly, as we all would want. And you are not stupid for having
> trouble reading it as a tutorial document. We all share such trouble,
> from time to time.

Indeed, the C++ Standard is not perfect. But if this is a particular
example of something that could be improved or flat-out fixed
(depending on your mindset and interpretation of the term
"end-of-file"), shouldn't it be done, so that everyone sane reading
the new and improved version can come to the same conclusion? I can't
discount the possibility that I'm the only person that interprets the
expression "end-of-file" the way that I do, but in all likelihood
there are others (including some of those who know a lot more about
C++ than me). I could say "bring me a hammer", and by that also mean
bring me a nail, a screwdriver, wash the car, and paint the house, but
few would disagree that my language for expressing that is ambiguous
to the point of being incorrect, at least to express what I mean.

> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com

                                                  Tommy McDaniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Tommy McDaniel" <tdmj@hotmail.com> wrote in message
news:c0fba064.0206121010.5f3a5f47@posting.google.com...

> > > > Now, I am aware that using ios::binary as an openmode will result in
> > > > the file not being opened.
> >
> > If it doesn't exist, you mean. Otherwise, it should open just fine, with
> > read and write permissions, IIRC.
>
> No, I meant what I stated, although looking back I may have stated it
> ambiguously. I meant if the entire openmode was just ios::binary. I
> also believed until recently that such a thing would result in the
> file being opened for reading and writing, but the problem I was
> having that originated all this only manifested itself when using only
> ios::binary for an openmode. It was pointed out to me in comp.lang.c++
> that using only ios::binary was illegal (which really surprised me
> because the book I have gives explicit examples of using only
> ios::binary and then being able to input and output, and I seemed to
> remember doing it previously at some point in time on some computer or
> other), and when I searched in the Standard, sure enough, there was
> 27.8.1.3, which says that if the openmode isn't in the provided table
> the file won't be opened, and ios::binary alone isn't in the table.
> There could be something else in the Standard that changes that, since
> I am not an expert here, but if there is I don't know about it.

It is indeed true that ios::binary is not a permissible open mode.
Some constructors, such as basic_ifstream(const char *, ios::openmode),
provide implicit additional mode bits that rescue a bald ios::binary.
But the case you cite has no such implicit bits. I stand corrected.

> > > > And that's it. Now the way I see it, 1 obviously doesn't apply.
> > > > Leaving 2. However, the wording says "end-of-file occurs." Can one
> > > > really reach the end of a file that can't be read to start with?
> >
> > Sure can. Right out of the starting gate.
>
> Having thought a little about this since I read that, it occurs to me
> that, in my opinion, such a thing may be true in some cases but not
> others. If one takes an expression that goes "end-of-<word>", where
> <word> is a verb, it seems to me that one can usually reach the end at
> any point. But if <word> is a noun, it doesn't seem the same to me in
> all circumstances. Consider "end-of-cord". One can't reach the end of
> the cord at the beginning unless one starts there.

Or the cord has zero length, which is the same thing.

>                                                   Taking the analogy
> to files, one would be at the end of the file from the very beginning
> only if one explicitly started at that particular point.

Or the file had zero length, which is the same thing.

>                                                        But the
> Standard, that I know of, doesn't specify such a thing on open()
> errors.

Nor does it specify a lot of such corner cases, unless they happen
to be (regrettable) exceptions to a general rule.

>        Also, consider if the file doesn't even exist. How can one be
> at the end of a file that doesn't even exist?

Because that's where you began?

>                                             I could possibly see how
> it could be declared (which it isn't) that when one can't open a file
> one shall be at the end of it automatically, but a file that doesn't
> even exist?

You are clearly thinking like a native English speaker, not a programmer.
English is full of special constructs that distinguish zero, one, and
more than one. Good testing and looping code is robust enough to take
all these possibilities in stride, ideally with no special-case code.
The C++ Standard is chock full of constructs that survive zero-ness,
one-ness, and many-ness with equal ease.

> > >              Unfortunately, read() only mentions reaching end-of-file.
> > > > Is the possibility illustrated by my sample code above, of trying to
> > > > read from a file that can't be read, either not covered by the
> > > > Standard, covered ambiguously by option 2 above, or covered elsewhere
> > > > in the Standard?
> >
> > The middle one.
>
> If it is in fact covered ambiguously by the statement "end-of-file",
> doesn't this pretty much rise to the level of an error?

Well, yes, but. The C++ Standard is also chock full of downright erroneous
and/or inconsistent statements. The C++ committee has so far spent most
of its time dealing with these. If you think the problem is severe
enough, then write up a Defect Report, preferably with suggested wording
changes to fix the problem. If you post it here, one of the moderators
will likely submit it to the committee on your behalf. Eventually, it
will get committee time and a resolution of some sort.

>                                                        Some people
> may interpret "end-of-file" to include when a file can't be opened,
> but I don't know that that is a universal interpretation of that
> expression.

As a general rule, an open failure is signaled through a different
channel than merely reporting an instant end-of-file. But if you
ignore that channel and get an instant end-of-file when you try to
read the stream, I consider that pretty reasonable behavior.

>         I certainly don't see it that way, meaning that there are
> probably plenty of other people that see it the same way, not that I
> know.

Very likely, FWIW. The C++ Standard is not intended to be a tutorial
document, however.

> > >                    Does the Standard define 'end-of-file occurring'
> > > > somewhere I don't know about? If it is covered as-is by option 2, I
> > > > find that extremely ambiguous, or just plain wrong (how many
> > > > end-of-book's have you gotten to when you couldn't read the book to
> > > > start with?).
> >
> > Happens to me all the time, particularly when I'm too busy to open the
> > book. Or the book wasn't where I hoped to find it. Or...
>
> Do you really consider yourself to have gotten to the end of those
> books?

Yes.

>       In that case, I've gotten to the end of a lot more things than
> I knew. Like most books ever published.

So you have.

>                                        In my mind, not starting
> something isn't equal to reaching the end of it. If not, then I
> proudly declare that I am done with my 99.9999% compliant C++
> compiler, my absolutely greatest OS in the world, and a lot of other
> things.

Congratulations. Zero-length strings are indeed so ubiquitous that
they help you concoct all sorts of farcical conclusions. But that
doesn't diminish their utility in many more serious contexts.

> > None of the above. The C++ Standard is not always worded as precisely,
> > or as clearly, as we all would want. And you are not stupid for having
> > trouble reading it as a tutorial document. We all share such trouble,
> > from time to time.
>
> Indeed, the C++ Standard is not perfect. But if this is a particular
> example of something that could be improved or flat-out fixed
> (depending on your mindset and interpretation of the term
> "end-of-file"), shouldn't it be done, so that everyone sane reading
> the new and improved version can come to the same conclusion?

Sure it should be done, if you can find the energy to whomp up a DR,
and if a moderator is convinced to submit it, and if the committee
can find time to process it in the near future, etc. The work on a
committee of volunteers gets done by people who volunteer to do the
work.

>                                                              I can't
> discount the possibility that I'm the only person that interprets the
> expression "end-of-file" the way that I do, but in all likelihood
> there are others (including some of those who know a lot more about
> C++ than me). I could say "bring me a hammer", and by that also mean
> bring me a nail, a screwdriver, wash the car, and paint the house, but
> few would disagree that my language for expressing that is ambiguous
> to the point of being incorrect, at least to express what I mean.

Some would even say that it's downright wrong, since it's not likely
you'll find anybody acculturated to share that meaning with you.
The wording at issue here is not so clear cut, however.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Tommy McDaniel" <tdmj@hotmail.com> wrote in message
news:c0fba064.0206042356.2a85744b@posting.google.com...

> tdmj@hotmail.com (Tommy McDaniel) wrote in message
news:<c0fba064.0205310157.68adbb9d@posting.google.com>...
> > I asked the following in comp.lang.c++ a couple of times, and since no
> > one responded I assume that the question is either really stupid or
> > really hard. Consider the following code:
> >
> > #include <fstream>
> > ...
> > int main()
> > {
> >    fstream file("my_file", ios::binary);
> >    int temp;
> >
> >    file.read(reinterpret_cast<char *>(&temp), sizeof(temp));
> > ...
> > }
> >
> > Now, I am aware that using ios::binary as an openmode will result in
> > the file not being opened.

If it doesn't exist, you mean. Otherwise, it should open just fine, with
read and write permissions, IIRC.

>                             However, I do not understand why the code
> > results in eofbit being set for file. According to section 27.6.1.3 of
> > the Standard, under the description of read(), it first mentions what
> > to do if !good(). Since the brand new stream is in fact good, we read
> > on. It then gives the two conditions under which extraction stops:
> >
> > 1. n characters are stored.
> > 2. end-of-file occurs on the input sequence (in which case the
> > function calls setstate(failbit|eofbit), which may throw
> > ios_base::failure).
> >
> > And that's it. Now the way I see it, 1 obviously doesn't apply.
> > Leaving 2. However, the wording says "end-of-file occurs." Can one
> > really reach the end of a file that can't be read to start with?

Sure can. Right out of the starting gate.

>                                                                   There
> > is no such ambiguity in the description of write(), which gives an
> > ending condition of "inserting in the output sequence fails"
> > (27.6.2.6).

Writing and reading are fundamentally asymmetrical. The former generates
and disposes, while the latter attempts to consume and parse. They thus
have different failure modes.

>              Unfortunately, read() only mentions reaching end-of-file.
> > Is the possibility illustrated by my sample code above, of trying to
> > read from a file that can't be read, either not covered by the
> > Standard, covered ambiguously by option 2 above, or covered elsewhere
> > in the Standard?

The middle one.

>                    Does the Standard define 'end-of-file occurring'
> > somewhere I don't know about? If it is covered as-is by option 2, I
> > find that extremely ambiguous, or just plain wrong (how many
> > end-of-book's have you gotten to when you couldn't read the book to
> > start with?).

Happens to me all the time, particularly when I'm too busy to open the
book. Or the book wasn't where I hoped to find it. Or...

>              Actually, this problem would seem to creep up any time
> > you try to read from a stream that can't be read from yet still has
> > goodbit set, which the above is just an example of.

Yes.

> Anyone? Surely there's someone out there that either has an opinion on
> this or doesn't have an opinion on this. Beyond curing my paranoia, if
> it is in fact a defect then it is something that should be recognized
> as such so that it can be fixed whenever the Standard is updated. And
> if I'm just a moron and it's not a defect in one way or another, that
> can be good to know too.

None of the above. The C++ Standard is not always worded as precisely,
or as clearly, as we all would want. And you are not stupid for having
trouble reading it as a tutorial document. We all share such trouble,
from time to time.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

tdmj@hotmail.com (Tommy McDaniel) wrote in message news:<c0fba064.0205310157.68adbb9d@posting.google.com>...
> I asked the following in comp.lang.c++ a couple of times, and since no
> one responded I assume that the question is either really stupid or
> really hard. Consider the following code:
>
> #include <fstream>
> ...
> int main()
> {
>    fstream file("my_file", ios::binary);
>    int temp;
>
>    file.read(reinterpret_cast<char *>(&temp), sizeof(temp));
> ...
> }
>
> Now, I am aware that using ios::binary as an openmode will result in
> the file not being opened. However, I do not understand why the code
> results in eofbit being set for file. According to section 27.6.1.3 of
> the Standard, under the description of read(), it first mentions what
> to do if !good(). Since the brand new stream is in fact good, we read
> on. It then gives the two conditions under which extraction stops:
>
> 1. n characters are stored.
> 2. end-of-file occurs on the input sequence (in which case the
> function calls setstate(failbit|eofbit), which may throw
> ios_base::failure).
>
> And that's it. Now the way I see it, 1 obviously doesn't apply.
> Leaving 2. However, the wording says "end-of-file occurs." Can one
> really reach the end of a file that can't be read to start with? There
> is no such ambiguity in the description of write(), which gives an
> ending condition of "inserting in the output sequence fails"
> (27.6.2.6). Unfortunately, read() only mentions reaching end-of-file.
> Is the possibility illustrated by my sample code above, of trying to
> read from a file that can't be read, either not covered by the
> Standard, covered ambiguously by option 2 above, or covered elsewhere
> in the Standard? Does the Standard define 'end-of-file occurring'
> somewhere I don't know about? If it is covered as-is by option 2, I
> find that extremely ambiguous, or just plain wrong (how many
> end-of-book's have you gotten to when you couldn't read the book to
> start with?). Actually, this problem would seem to creep up any time
> you try to read from a stream that can't be read from yet still has
> goodbit set, which the above is just an example of.

Anyone? Surely there's someone out there that either has an opinion on
this or doesn't have an opinion on this. Beyond curing my paranoia, if
it is in fact a defect then it is something that should be recognized
as such so that it can be fixed whenever the Standard is updated. And
if I'm just a moron and it's not a defect in one way or another, that
can be good to know too.

                                                 Tommy McDaniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I asked the following in comp.lang.c++ a couple of times, and since no
one responded I assume that the question is either really stupid or
really hard. Consider the following code:

#include <fstream>
...
int main()
{
   fstream file("my_file", ios::binary);
   int temp;

   file.read(reinterpret_cast<char *>(&temp), sizeof(temp));
...
}

Now, I am aware that using ios::binary as an openmode will result in
the file not being opened. However, I do not understand why the code
results in eofbit being set for file. According to section 27.6.1.3 of
the Standard, under the description of read(), it first mentions what
to do if !good(). Since the brand new stream is in fact good, we read
on. It then gives the two conditions under which extraction stops:

1. n characters are stored.
2. end-of-file occurs on the input sequence (in which case the
function calls setstate(failbit|eofbit), which may throw
ios_base::failure).

And that's it. Now the way I see it, 1 obviously doesn't apply.
Leaving 2. However, the wording says "end-of-file occurs." Can one
really reach the end of a file that can't be read to start with? There
is no such ambiguity in the description of write(), which gives an
ending condition of "inserting in the output sequence fails"
(27.6.2.6). Unfortunately, read() only mentions reaching end-of-file.
Is the possibility illustrated by my sample code above, of trying to
read from a file that can't be read, either not covered by the
Standard, covered ambiguously by option 2 above, or covered elsewhere
in the Standard? Does the Standard define 'end-of-file occurring'
somewhere I don't know about? If it is covered as-is by option 2, I
find that extremely ambiguous, or just plain wrong (how many
end-of-book's have you gotten to when you couldn't read the book to
start with?). Actually, this problem would seem to creep up any time
you try to read from a stream that can't be read from yet still has
goodbit set, which the above is just an example of.

                                                   Tommy McDaniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]