fgetc() past EOF

[José de Paula]

I'm writing a little BrainFuck interpreter (by the way, gbf.sourceforge.net)
that can read the BrainFuck program from stdin; when the interpreter gets an
EOF, it stops reading the BrainFuck program and starts interpreting it;
BrainFuck has i/o facilities, and I use stdin/stdout to receive/spit out the
BrainFuck fluff. The problem is that stdin seems to lock after fgetc() gets
an EOF from it, and doesn't reset anymore. If I get the BrainFuck program
text from a file, it all works correctly, but if I read the text from stdin,
get an EOF, and keep on trying to read from it, the interpreter hangs. How
can I reset the EOF status (if there is such a thing) of stdin? Or is there
a workaround for this problem?

If you want to test-drive it, please mail me.

--
Emacs is a great operating system---it lacks a good editor, though.

[Hallvard B Furuseth]

José de Paula wrote:

I'm writing a little BrainFuck interpreter (by the way, gbf.sourceforge.net)
that can read the BrainFuck program from stdin; when the interpreter gets an
EOF, it stops reading the BrainFuck program and starts interpreting it;
BrainFuck has i/o facilities, and I use stdin/stdout to receive/spit out the
BrainFuck fluff. The problem is that stdin seems to lock after fgetc() gets
an EOF from it, and doesn't reset anymore.
Of course. EOF means the file ended. It's not part of the input
stream.
How
can I reset the EOF status (if there is such a thing) of stdin? Or is there
a workaround for this problem?

clearerr(stdin) works on my system (Solaris), but I don't know how
portable it is. You should ask on a newsgroup for the OS and C
implementation you are using. Maybe a safer way would be to re-open the
terminal, e.g. freopen("/dev/tty", "r", stdin) if you are using Unix.
However, I'm not sure if that breaks input from programs that use PTYs,
like expect. Anyway, that belongs on a Unix group.

--
Hallvard

[Ben Pfaff]

José de Paula <jo***********@ig.com.br> writes:

I'm writing a little BrainFuck interpreter (by the way, gbf.sourceforge.net)
that can read the BrainFuck program from stdin; when the interpreter gets an
EOF, it stops reading the BrainFuck program and starts interpreting it;
BrainFuck has i/o facilities, and I use stdin/stdout to receive/spit out the
BrainFuck fluff. The problem is that stdin seems to lock after fgetc() gets
an EOF from it, and doesn't reset anymore. If I get the BrainFuck program
text from a file, it all works correctly, but if I read the text from stdin,
get an EOF, and keep on trying to read from it, the interpreter hangs. How
can I reset the EOF status (if there is such a thing) of stdin? Or is there
a workaround for this problem?

The behavior in the face of end-of-file on stdin varies among C
libraries. Some behave as you describe; others will happily
continue to read after sending end-of-file once. There is no
standard way to "reset" one that has the former behavior.

I recommend reading the program from a different file, perhaps
one whose name is specified on the command line. This would
align your interpreter's behavior with many others, such as Perl,
Python, sed, the Bourne shell, and so on. It would also make it
possible to make programs written in the language invocable on
Unix-like command lines using the standard Unix #! syntax.
--
"Given that computing power increases exponentially with time,
algorithms with exponential or better O-notations
are actually linear with a large constant."
--Mike Lee

[José de Paula]

Em Sat, 17 Jan 2004 07:57:57 +0100, Hallvard B Furuseth escreveu:
<snip>

clearerr(stdin) works on my system (Solaris), but I don't know how
portable it is. You should ask on a newsgroup for the OS and C
implementation you are using. Maybe a safer way would be to re-open the
terminal, e.g. freopen("/dev/tty", "r", stdin) if you are using Unix.
However, I'm not sure if that breaks input from programs that use PTYs,
like expect. Anyway, that belongs on a Unix group.

Thank you. freopen() worked for me; clearerr() didn't. I forgot to
mention that my system is a FreeBSD on a i386, gcc 3.2 (but still dreaming
with a IBM Power IV...)

--
Emacs is a great operating system---it lacks a good editor, though.

[Chris Torek]

>José de Paula <jo***********@ig.com.br> writes:

... How can I reset the EOF status (if there is such a thing)
of stdin?

In article <news:87************@pfaff.stanford.edu>
Ben Pfaff <bl*@cs.stanford.edu> writes:The behavior in the face of end-of-file on stdin varies among C
libraries. Some behave as you describe; others will happily
continue to read after sending end-of-file once. There is no
standard way to "reset" one that has the former behavior.

Well, clearerr() is standard and will (must) reset the EOF indicator
(so that feof(stdin) becomes false) along with the error indicator.
But it is true that there is no guarantee that a subsequent getchar()
will even try to read more input. On some systems I suspect it
would not without OS assistance -- e.g., on EXEC-8 on a Univac,
@FIN on a line by itself is the method one uses to signal end-of-file,
but it likely works by marking something the C runtime would not
have access to, since @ lines bypass just about everything except
the host OS (@@ lines apparently bypass the OS too -- @@TERM seems
to shut off the connection at the concentrator).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

José de Paula wrote:

Hallvard B Furuseth escreveu:

<snip>

clearerr(stdin) works on my system (Solaris), but I don't know
how portable it is. You should ask on a newsgroup for the OS
and C implementation you are using. Maybe a safer way would be
to re-open the terminal, e.g. freopen("/dev/tty", "r", stdin)
if you are using Unix. However, I'm not sure if that breaks
input from programs that use PTYs, like expect. Anyway, that

belongs on a Unix group.

Thank you. freopen() worked for me; clearerr() didn't. I forgot
to mention that my system is a FreeBSD on a i386, gcc 3.2 (but
still dreaming with a IBM Power IV...)

Fine if it is only for your own amusement. The only clean and
portable way is to separate the files, IMO.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[AM]

Chris Torek <no****@torek.net> wrote in message news:<bu*********@enews4.newsguy.com>...

Well, clearerr() is standard and will (must) reset the EOF indicator
(so that feof(stdin) becomes false) along with the error indicator.
But it is true that there is no guarantee that a subsequent getchar()
will even try to read more input. On some systems I suspect it
would not without OS assistance -- e.g., on EXEC-8 on a Univac,
@FIN on a line by itself is the method one uses to signal end-of-file,
but it likely works by marking something the C runtime would not
have access to, since @ lines bypass just about everything except
the host OS (@@ lines apparently bypass the OS too -- @@TERM seems
to shut off the connection at the concentrator).

Not quite. @FIN was (is?) the end of job card. End of file was @EOF.
In practice, input to a processor - compiler, linker, assembler - was
terminated by the @ character in column 1.

The @@ commands were obeyed out of sequence - "transparent mode". In
demand mode processing, if you had a number of commands waiting to be
executed, you could send e.g., @@TERM, and it would be obeyed
essentially instantaneously by the executive. I forget the @@ comands,
but ISTR they included ASG (mass storage assignment), FREE (release
mass storage back to the system) and SYM - send a print or punch file
to the appropriate device. It's all a bit hazy now since it's 20yrs
since I last used a Univac...

rgds A