Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:
> What is strange (to me) is the fact that the UNIX conole driver
> has anything to do with iostream::eof.

I find it strange that you find it starnge! My expectation, perhaps
due to my lengthy UNIX background, is that getting EOF on an input
stream is a transient condition, even from a file, since files may
grow longer. Indeed, there is a UNIX utility called 'tail' taking a
'-f' argument which instructs it to ignore EOF on the stream it's
reading and to keep trying to read more input, in the expectation
that some will appear.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3802f1c2.589334558@news.internetconnect.net>,
  phalpern@newview.org (Pablo Halpern) wrote:
> Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>
> >Pablo Halpern wrote:

> >> The reporting of end-of-file conditions by a device like the
console is
> >> not part of the C++ standard.

> >Strange.

> I don't find it strange. The exact meaning of end-of-file is an
> OS/device concept.

Partially.  Strictly speaking, end of file *is* OS dependant, in all
ways, and there is *no* end of file on a console device under UNIX.  At
all.  However, strictly speaking, the eof condition in the C++ is not
related to this OS dependant end of file -- it is simply a bit which is
set when an attempt to get more characters fails.  A single attempt.
And it is a bit which is reset explicitly by the user.  After being
reset, the next read should attempt to get more characters.  Which, of
course, if there is a real end of file in the system, and the conditions
which caused it haven't changed, will also fail.

Another poster has pointed out what actually happens under Unix.
Entering a control D doesn't create an end of file condition in the OS.
But under certain conditions (an empty line buffer), it does cause a
behavior which will normally be interpreted as failure by the user
program.  For the single request currently active -- if you try again,
you will only get an end of file if the user retaps a control D.

> >> There is nothing in the standard that
> >> prevents the device-level end-of-file condition from changing from
true
> >> to false. The eof() function will only return true only until it is
> >> cleared. Once cleared, it will only be set true again if the device
> >> reports eof again. In the case of the console on your OS (Unix?),
the
> >> device-level eof condition appears to be transient. The
second-to-last
> >> statement (cin.get()) succeedes and eof() is false on entry to the
while
> >> loop, so it never loops.

> >Does the standard (C or C++) says so explicitly or is
> >it implicit ?

> I'm not sure what you're asking. I couldn't find anything in the
> standard *requiring* eof() to be sticky. (That doesn't mean it isn't
> there somewhere; it must might be hard to find.) The standard defines
> input operations (ultimately) in terms of the streambuf operations
> uflow() and underflow(). The way in which these two functions are
> defined imply a certain level of statelessness (or device-specific
> state) with regard to the availability of more characters from the
> input device.

In general, the only place where there is such state is in ios, not
streambuf.  If you reset it, the state is gone.  I would interpret the
lack of explicit state in filebuf as requiring precisely the opposite as
what Valentin expects: if I see end of file, reset it, and wait a while,
I expect the library to try to read again.  What happens then will very
much depend on the OS definition of end of file, but for many OS's
(including Unix, and I think Windows), if more data has become
available, the read will succeed.

--
James Kanze                    mailto:James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:

>Hyman Rosen wrote:

>> Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:
>> > Pablo Halpern wrote:
>> > > The reporting of end-of-file conditions by a device like the console is
>> > > not part of the C++ standard.

>> > Strange.

>> Not strange at all, once you know how the UNIX console driver works
>> in standard "cooked" mode.

>What is strange (to me) is the fact that the UNIX conole driver
>has anything to do with iostream::eof.

An istream gets its data from someplace. It might be an in-memory
buffer (a string or char array), or a disk file, or a special-purpose
piece of hardware, or a terminal, or ....

The streambuf "overflow" function as specialized for the particular
input stream determines what constitutes eof. If the console gets
treated like a file on a particular OS and you use the general-purpose
OS read function, you'll get whatever the console driver provides.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:

>Pablo Halpern wrote:
>
>> The reporting of end-of-file conditions by a device like the console is
>> not part of the C++ standard.
>
>Strange.

I don't find it strange. The exact meaning of end-of-file is an
OS/device concept.

>> There is nothing in the standard that
>> prevents the device-level end-of-file condition from changing from true
>> to false. The eof() function will only return true only until it is
>> cleared. Once cleared, it will only be set true again if the device
>> reports eof again. In the case of the console on your OS (Unix?), the
>> device-level eof condition appears to be transient. The second-to-last
>> statement (cin.get()) succeedes and eof() is false on entry to the while
>> loop, so it never loops.
>
>Does the standard (C or C++) says so explicitly or is
>it implicit ?

I'm not sure what you're asking. I couldn't find anything in the
standard *requiring* eof() to be sticky. (That doesn't mean it isn't
there somewhere; it must might be hard to find.) The standard defines
input operations (ultimately) in terms of the streambuf operations
uflow() and underflow(). The way in which these two functions are
defined imply a certain level of statelessness (or device-specific
state) with regard to the availability of more characters from the input
device.

-------------------------------------------------------------
Pablo Halpern                            phalpern@newview.org

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:
> Pablo Halpern wrote:
> > The reporting of end-of-file conditions by a device like the console is
> > not part of the C++ standard.
> Strange.

Not strange at all, once you know how the UNIX console driver works
in standard "cooked" mode. In this mode, non-special characters typed
at the keyboard are kept by the device driver in a buffer, to allow
editing by char-erase and line-erase characters (^H and ^U, or # and @
in the old days). Meanwhile, a process that is trying to read from the
console is supended on its read system call. When a CR is entered, the
driver changes that to a LF, adds it to the buffer, and makes the
characters from the buffer available to the process, whereupon the
read system call returns with the number of characters read. If a ^D
is typed, the driver makes whatever characters are buffered available
immediately, and again read returns with the number of characters read.
If there happened to be no characters in the buffer when the ^D was
typed, then read would return with 0. Programs take such a return value
as an indication of EOF. If the program chooses to continue to attempt
to read the console, subsequent reads continue as before, and will
return any further data typed. There is no way to tell the a program
that the EOF condition is permanent.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hyman Rosen wrote:

> Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:
> > Pablo Halpern wrote:
> > > The reporting of end-of-file conditions by a device like the console is
> > > not part of the C++ standard.

> > Strange.

> Not strange at all, once you know how the UNIX console driver works
> in standard "cooked" mode.

What is strange (to me) is the fact that the UNIX conole driver
has anything to do with iostream::eof.

--

Valentin Bonnard


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:

>What does the standard says about the following:
>
>#include <iostream>
>
>using namespace std;
>int main()
>{
>  while (!cin.eof()) cin.get();
>  cout << "EOF" << endl;
>  cin.clear ();
>  cin.get ();
>  while (cin.eof()) cin.get();
>}
>
>With g++, if I type ^D<enter> the programs prints EOF
>and exits. Is it correct behaviour ? (It seems to me
>that the program should loop forever.)

The reporting of end-of-file conditions by a device like the console is
not part of the C++ standard. There is nothing in the standard that
prevents the device-level end-of-file condition from changing from true
to false. The eof() function will only return true only until it is
cleared. Once cleared, it will only be set true again if the device
reports eof again. In the case of the console on your OS (Unix?), the
device-level eof condition appears to be transient. The second-to-last
statement (cin.get()) succeedes and eof() is false on entry to the while
loop, so it never loops.

-------------------------------------------------------------
Pablo Halpern                            phalpern@newview.org

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pablo Halpern wrote:

> The reporting of end-of-file conditions by a device like the console is
> not part of the C++ standard.

Strange.

> There is nothing in the standard that
> prevents the device-level end-of-file condition from changing from true
> to false. The eof() function will only return true only until it is
> cleared. Once cleared, it will only be set true again if the device
> reports eof again. In the case of the console on your OS (Unix?), the
> device-level eof condition appears to be transient. The second-to-last
> statement (cin.get()) succeedes and eof() is false on entry to the while
> loop, so it never loops.

Does the standard (C or C++) says so explicitly or is
it implicit ?

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hyman Rosen wrote:

> It's not sticky if you clear it! Why should it be?

Don't know.

> Files can grow
> longer, more input can be available at a terminal, and so forth.

But I want to know what the _standard_ says. I am not
used to the i/o section presentation. (You have to
understand everything before you understand anything.)

--

Valentin Bonnard


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37F032A0.4384@wanadoo.fr>,
  Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> What does the standard says about the following:

Not much, I suspect.

> #include <iostream>
>
> using namespace std;
> int main()
> {
>   while (!cin.eof()) cin.get();
>   cout << "EOF" << endl;
>   cin.clear ();
>   cin.get ();
>   while (cin.eof()) cin.get();
> }

> With g++, if I type ^D<enter> the programs prints EOF
> and exits. Is it correct behaviour ? (It seems to me
> that the program should loop forever.)

In this particular case, so would I. On the other hand, I doubt you
could argue one way or another from the standard -- what should the
behavior be, for example, if you were reading from a file, and between
the first EOF and the second while, someone else wrote to the file?

Practically, I don't think any implementation on UNIX will do other than
g++ here.  It would require either preventing reading a file that has
grown, or special handling for the keyboard.  IMHO, definitly not worth
the effort, even if it is slightly "more correct".

FWIW: The problem is tricker if you are accessing streambuf directly.
Consider the following:

    streambuf* sb = cin.rdbuf() ;
    while ( sb->sgetc() != EOF )
        sb->sbumpc() ;
    sb->sbumpc() ;
    //  Any bets on the results of the next sb->sgetc() ?

Moral: never try to read a streambuf once you've seen eof -- I don't
know exactly what the standard says, but I do know that in practice, you
cannot count on the results.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

It's not sticky if you clear it! Why should it be? Files can grow
longer, more input can be available at a terminal, and so forth.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

What does the standard says about the following:

#include <iostream>

using namespace std;
int main()
{
  while (!cin.eof()) cin.get();
  cout << "EOF" << endl;
  cin.clear ();
  cin.get ();
  while (cin.eof()) cin.get();
}

With g++, if I type ^D<enter> the programs prints EOF
and exits. Is it correct behaviour ? (It seems to me
that the program should loop forever.)

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]