Re: Testing for EOF in file with binary data

From:

Richard Herring <junk@[127.0.0.1]>

Newsgroups:

comp.lang.c++

Date:

Mon, 15 May 2006 11:35:14 +0100

Message-ID:

<FsDvMNbilFaEFwIA@baesystems.com>

In message <IoSdnXH6Gra91P7ZRVn-sQ@giganews.com>, P.J. Plauger
<pjp@dinkumware.com> writes

"mlimber" <mlimber@gmail.com> wrote in message
news:1147355515.295043.292200@g10g2000cwb.googlegroups.com...

[cross-posting deleted]

David Warner wrote:

I am working on a C app that needs to read print files generated by lp
that contain HP LaserJet PCL codes. If the PCL contains binary data to
define a bit map to be printed on the page, either icon or soft-font
download, the EOF test ends prematurely and does not read the entire
file. How do I get around testing for EOF and not detect the EOF value
within the file? Am I missing something?

We prefer std::fstreams in this group, but the same solution can work
with C or C++ style file streams: use the file size rather than the EOF
character to determine how much data you read. You can use
fstream::seekg() and fstream::tellg() in C++ or the C equivalents to
get that info.

The real answer is that the return from fgetc and friends in an int,
not a char. The value of EOF is distinguishable from any char value
you read from a binary stream.

The OP hasn't actually made it clear whether his "EOF" means the macro
or is just an abbreviation for "end-of-file condition", Is he actually
comparing a char against the macro EOF, or is he calling the feof()
function?

In the latter case, the first question is: has he actually opened the
file in binary mode? In text mode, there's at least one OS out there
that will interpret control-Z as end-of-file and produce a premature
termination.

--
Richard Herring