fgetc() past EOF

  • Thread starter =?iso-8859-1?q?Jos=E9_de_Paula?=
  • Start date
?

=?iso-8859-1?q?Jos=E9_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.
 
B

Ben Pfaff

José de Paula said:
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.
 
H

Hallvard B Furuseth

José de Paula said:
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.
 
?

=?iso-8859-1?q?Jos=E9_de_Paula?=

Em Sat, 17 Jan 2004 07:57:57 +0100, Hallvard B Furuseth escreveu:
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...)
 
C

Chris Torek

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).
 
C

CBFalconer

José de Paula said:
Hallvard B Furuseth escreveu:


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.
 
A

AM

Chris Torek said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

getc() != fgetc() ?? 3
fgetc 37
getc fgetc 7
A process take input from /proc/<pid>/fd/0, but won't process it 0
Working with files 1
Text processing 29
Determining EOF using fseek()? 6
getchar() and EOF confusion 21

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top