Testing for EOF in file with binary data

[David Warner]

Greetings!

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?

More Data:

If the print file just contains text data or does not have a bit map
value, the print file is read correctly.

Suggestions?

Thanks in advance!

David Warner
--
comp.lang.c.mod erated - moderation address: cl**@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[mlimber]

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

Cheers! --M

[P.J. Plauger]

"mlimber" <ml*****@gmail. com> wrote in message
news:11******** **************@ g10g2000cwb.goo glegroups.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.

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

[Richard Herring]

In message <Io************ ********@gigane ws.com>, P.J. Plauger
<pj*@dinkumware .com> writes

"mlimber" <ml*****@gmail. com> wrote in message
news:11******* *************** @g10g2000cwb.go oglegroups.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

[P.J. Plauger]

"Richard Herring" <ju**@[127.0.0.1]> wrote in message
news:Fs******** ******@baesyste ms.com...

In message <Io************ ********@gigane ws.com>, P.J. Plauger
<pj*@dinkumware .com> writes

"mlimber" <ml*****@gmail. com> wrote in message
news:11****** *************** *@g10g2000cwb.g ooglegroups.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?

Looked pretty clear to me that he's reading a character, storing it in
a char, then comparing it to EOF -- which of course destroys the
important difference between (int)EOF and (char)EOF. But then I might
be interpolating over aggressively.
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.

Right, and those systems present an early end-of-file condition, which
is different from the OPs concern that (char)EOF look like an early
end-of-file.

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

[Jerry Coffin]

In article <cl************ ****@plethora.n et>,
da******@westba se.com says...

Greetings!

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?

It's easiest to help if you include a minimal piece of
code that demonstrates the problem.

One thing that often causes this is code something like:

char ch;

while (EOF!=(ch=getc( file)))
process(ch);
the crucial point here is that ch is a char -- for things
to work correctly, it really needs to be an int.

Another possible problem is the way the OS handles the
file you're reading from. A stream will often have a
"cooked" and a "raw" mode. In cooked mode, certain
control codes (e.g. ctrl-D on UNIX and ctrl-C on Windows)
are given special treatment; in raw mode, everything is
passed through without interpretation. This _tends_ to
arise most often if you do something like redirecting
standard input to read from a binary file. Changing this
is usually OS-specific.

--
Later,
Jerry.

The universe is a figment of its own imagination.
--
comp.lang.c.mod erated - moderation address: cl**@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Richard Bos]

David Warner <da******@westb ase.com> 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?

fopen() it in binary rather than text mode.

Richard
--
comp.lang.c.mod erated - moderation address: cl**@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Earl Purple]

David Warner wrote:

Greetings!

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?

That you have posted this to multiple newsgroups and in some of them at
least it is off-topic. I am posting this from comp.lang.c++ and it is
off-topic here.
--
comp.lang.c.mod erated - moderation address: cl**@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[Michael Tiomkin]

David Warner wrote:

Greetings!

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?

More Data:

If the print file just contains text data or does not have a bit map
value, the print file is read correctly.

Suggestions?

1. Try to fopen a file using binary option, e.g. "rb". Reading a file
as ASCII can confuse the I/O functions into thinking that the file had
prematurely ended.
2. If you use a test '((c=fgetc(F)) != EOF)', declare 'c' as an int,
not as a char. Another option is to avoid testing every character on
EOF, and using fread instead. When you wouldn't be able to read the
number of chars you asked in fread, the most probable reason is end of
file condition. If you want to be safe, you can test this condition
using feof function.

Michael
--
comp.lang.c.mod erated - moderation address: cl**@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

[gw7rib]

David Warner wrote:

Greetings!

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?

More Data:

If the print file just contains text data or does not have a bit map
value, the print file is read correctly.

Suggestions?

Thanks in advance!

David Warner

You haven't given much information, so I am having to guess a bit, but
I suspect you have fallen into the trap of using a char to store the
characters that you read in. Seems obvious to do, doesn't it? But
consider the following innocent-looking bit of code:

char ch;

ch = getc(fp);

On my system, a char can hold 256 different values - the same number as
there are of normal characters. getc will return a different value to
indicate end of file - but because it is stored in a char it becomes
the same as one of the normal characters before you get a chance to
compare it to anything. In my case, it can't tell the difference
between a -1 indicating the end of the file, and a character 255
validly read from the file.

Getc and the like return an int, and you need to store the value in an
int. Int is big enough to hold all the noraml characters and something
different to indicate end of file.

Hope this helps!

Paul.
--
comp.lang.c.mod erated - moderation address: cl**@plethora.n et -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.