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.moderated - moderation address: cl**@plethora.net -- 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.googlegr oups.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********************@giganews.com>, P.J. Plauger
<pj*@dinkumware.com> writes

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

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

"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@g10g2000cwb.google groups.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.net>,
da******@westbase.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.moderated - moderation address: cl**@plethora.net -- 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******@westbase.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.moderated - moderation address: cl**@plethora.net -- 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.moderated - moderation address: cl**@plethora.net -- 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.

[Vladimir Oka]

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?

With no code I can only guess that you're opening the file in text
mode. Have you tried opening it in binary mode?

Also, if you're problem is in C, why posto to all the C++ groups as
well?

[Google made me remove alt.comp.lang.learn-c-c++ from the list.]
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.

[Kenneth Brody]

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?

[...]

By definition, EOF cannot be in the file.

1) Have you opened the file in binary mode? (On some platforms, if you
open a binary file in text mode, the C runtime library may think
that you've hit EOF befire you really do.)

2) How are you checking for EOF? (Remember, fgetc returns an int, not
a char.)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.

[Joe Wright]

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

The EOF character is an anachronism, an artifact older simpler file
systems like CP/M. The EOF character had a value 0x1a (26) or ^Z.

The EOF character is not needed these days. You can stop C from checking
for it by opening your files in "rb" mode instead of "r" or "rt" mode.
You will still get the EOF indicator at the end of file but you will not
get it simply because you read a character 00011010.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.moderated - moderation address: cl**@plethora.net -- 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.moderated - moderation address: cl**@plethora.net -- 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.

[Brian Inglis]

On 11 May 2006 05:15:55 GMT in comp.lang.c.moderated, David Warner
<da******@westbase.com> 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?

Open input file with binary data in binary read mode?

#include <stdio.h>
#include <stdlib.h>

char name[FILENAME_MAX+1];
FILE *fp;
....
if (!(fp = fopen( name, "rb")))
{
perror( name );
exit(1);
}

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.

[pete]

Joe Wright wrote:

The EOF character

There is no EOF character.

--
pete
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.

[jjf]

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?

What was wrong with the answers you got when you posted a similar
question to comp.lang.c on April 27?
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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 Heathfield]

Joe Wright said:

The EOF character is not needed these days. You can stop C from checking
for it by opening your files in "rb" mode instead of "r" or "rt" mode.

The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
undefined behaviour.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.

[Keith Thompson]

jj*@bcs.org.uk writes:

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?

[snip] What was wrong with the answers you got when you posted a similar
question to comp.lang.c on April 27?

He cross-posted (simultaneously) to comp.lang.c and
comp.lang.c.moderated. Articles posted to comp.lang.c appear on
servers as soon as they're propagated. Articles posted to
comp.lang.c.moderated appear when the moderator gets around to
approving and posting them. (He also cross-posted to comp.lang.c++,
which is almost always a bad idea.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.

[jjf]

Keith Thompson wrote:

jj*@bcs.org.uk writes:

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?

[snip]

What was wrong with the answers you got when you posted a similar
question to comp.lang.c on April 27?

He cross-posted (simultaneously) to comp.lang.c and
comp.lang.c.moderated. Articles posted to comp.lang.c appear on
servers as soon as they're propagated. Articles posted to
comp.lang.c.moderated appear when the moderator gets around to
approving and posting them. (He also cross-posted to comp.lang.c++,
which is almost always a bad idea.)

He did that (and also cross-posted it to alt.comp.lang.learn-c-c++) for
the message which started this thread. That was sent in the early hours
of May 11 (or perhaps forwarded by the moderator at that time, though
since the replies didn't happen until May 22 I had guessed that May
10/11 was the date of original posting). I was referring to message
<da****************************@sn-ip.vsrv-sjc.supernews.net> which was
sent just to comp.lang.c on April 27, and got immediate answers. I may
be misinterpreting something, but I can't see what.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.

[Flash Gordon]

David Warner wrote:

Greetings!

I am working on a C app that needs to read print files generated by lp
If you are writing in C then you should not post to comp.lang.c++, C++
is a different language. If you are programming in C++ you should not
have posted to comp.lang.c. Cross-posting to both is rarely the correct
thing to do.
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?

<snip>

Open the file in binary mode rather than text mode.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.

[dan2online]

Richard Bos wrote:

David Warner <da******@westbase.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.

No.
FILE *fopen(const char *filename, const char *mode);
if the mode including 'b', it is in binary mode. Otherwise in text
mode.

[Flash Gordon]

David Warner wrote:

Greetings!

I am working on a C app that needs to read print files generated by lp
If you are writing in C then you should not post to comp.lang.c++, C++
is a different language. If you are programming in C++ you should not
have posted to comp.lang.c. Cross-posting to both is rarely the correct
thing to do.
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?

<snip>

Open the file in binary mode rather than text mode.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.

[Flash Gordon]

David Warner wrote:

Greetings!

I am working on a C app that needs to read print files generated by lp
If you are writing in C then you should not post to comp.lang.c++, C++
is a different language. If you are programming in C++ you should not
have posted to comp.lang.c. Cross-posting to both is rarely the correct
thing to do.
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?

<snip>

Open the file in binary mode rather than text mode.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
--
comp.lang.c.moderated - moderation address: cl**@plethora.net -- 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.