Testing for EOF in file with binary data

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: clcm@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.

re: Testing for EOF in file with binary data

In article <clcm-20060511-0035@plethora.net>,
dawarner@westbase.com says...[color=blue]
> 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?[/color]

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: clcm@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.

re: Testing for EOF in file with binary data

David Warner <dawarner@westbase.com> wrote:
[color=blue]
> 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?[/color]

fopen() it in binary rather than text mode.

Richard
--
comp.lang.c.moderated - moderation address: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> 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?[/color]
[color=blue]
> Am I missing something?
>[/color]
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: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> 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?[/color]

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: clcm@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.

re: Testing for EOF in file with binary data

[*Please* don't crosspost like this without a single-group F'up2...]

In comp.lang.c.moderated David Warner <dawarner@westbase.com> wrote:
[color=blue]
> download, the EOF test ends prematurely and does not read the entire
> file.[/color]

Not quite correct. *Your* way of handling that file and testing for
EOF fails. But that's not the fault of the compiler or library, but
of your code. Do yourself a favour: get a C textbook, and learn from
it. Don't just scan it for examples. Most importantly, you have to
understand why the return type of fgetch() is int.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
--
comp.lang.c.moderated - moderation address: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
>
> 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?[/color]
[...]

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:ThisIsASpamTrap@gmail.com>
--
comp.lang.c.moderated - moderation address: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> 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[/color]

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: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> 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?[/color]

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: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> 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[/color]

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: clcm@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.

re: Testing for EOF in file with binary data

On 11 May 2006 05:15:55 GMT in comp.lang.c.moderated, David Warner
<dawarner@westbase.com> wrote:
[color=blue]
>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?[/color]

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

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

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> 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?[/color]

In other words you can't know in advance, if the file will be purely
text or mixed text and binary data, (which practically makes it a
binary file). In this case, one option is to open the file in binary
mode using fopen() and use feof() to detect the end-of-file.

re: Testing for EOF in file with binary data

Joe Wright wrote:
[color=blue]
> The EOF character[/color]

There is no EOF character.

--
pete
--
comp.lang.c.moderated - moderation address: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> 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?[/color]

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: clcm@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.

re: Testing for EOF in file with binary data

Joe Wright said:
[color=blue]
> 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.[/color]

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: clcm@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.

re: Testing for EOF in file with binary data

jjf@bcs.org.uk writes:[color=blue]
> David Warner wrote:[color=green]
>> 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?[/color][/color]
[snip][color=blue]
> What was wrong with the answers you got when you posted a similar
> question to comp.lang.c on April 27?[/color]

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) kst-u@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: clcm@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.

re: Testing for EOF in file with binary data

Richard Heathfield wrote:[color=blue]
>
> Joe Wright said:
>[color=green]
> > 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.[/color]
>
> The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
> undefined behaviour.[/color]

Is it undefined, or implementation-defined? (Or is a particular
implementation allowed to define its behavior for something which
the standard calls "undefined behavior"?)

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

re: Testing for EOF in file with binary data

Keith Thompson wrote:[color=blue]
> jjf@bcs.org.uk writes:[color=green]
> > David Warner wrote:[color=darkred]
> >> 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?[/color][/color]
> [snip][color=green]
> > What was wrong with the answers you got when you posted a similar
> > question to comp.lang.c on April 27?[/color]
>
> 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.)[/color]

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
<dawarner-1EA66A.19255727042006@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: clcm@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.

re: Testing for EOF in file with binary data

Kenneth Brody <kenbrody@spamcop.net> writes:[color=blue]
> Richard Heathfield wrote:[color=green]
>> Joe Wright said:[color=darkred]
>> > 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.[/color]
>>
>> The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
>> undefined behaviour.[/color]
>
> Is it undefined, or implementation-defined? (Or is a particular
> implementation allowed to define its behavior for something which
> the standard calls "undefined behavior"?)[/color]

It's undefined behavior. As always, the implementation is allowed to
define the behavior if it chooses.

C99 7.19.5.3:

The argument mode points to a string. If the string is one of the
following, the file is open in the indicated mode. Otherwise, the
behavior is undefined.

with a footnote:

If the string begins with one of the above sequences, the
implementation might choose to ignore the remaining characters, or
it might use them to select different kinds of a file (some of
which might not conform to the properties in 7.19.2.

The listed modes are:

r
w
a
rb
wb
ab
r+
w+
a+
r+b or rb+
w+b or wb+
a+b or ab+

C90 worded this a little differently. It says:

The argument mode points to a string beginning with one of the
following sequences:
[...]

with a footnote:

Additional characters may follow these sequences.

Since the behavior for modes other than the listed ones was not
defined, the effect was the same: undefined behavior. The statement
that "Additional characters may follow these sequences" seems vacuous
(which is probably why it was changed in C99).

--
Keith Thompson (The_Other_Keith) kst-u@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: clcm@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.

re: Testing for EOF in file with binary data

Kenneth Brody wrote:[color=blue]
> Richard Heathfield wrote:[color=green]
> >
> > Joe Wright said:
> >[color=darkred]
> > > 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.[/color]
> >
> > The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
> > undefined behaviour.[/color]
>
> Is it undefined, or implementation-defined? (Or is a particular
> implementation allowed to define its behavior for something which
> the standard calls "undefined behavior"?)[/color]

It's undefined in standard C, and implementations are allowed to
"define UB". Most if not all do that in at least some ways. (A common
example is "\e", which is UB in standard C.)
--
comp.lang.c.moderated - moderation address: clcm@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.

re: Testing for EOF in file with binary data

Kenneth Brody <kenbrody@spamcop.net> wrote:
[color=blue]
> Richard Heathfield wrote:[color=green]
> >
> > Joe Wright said:
> >[color=darkred]
> > > 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.[/color]
> >
> > The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
> > undefined behaviour.[/color]
>
> Is it undefined, or implementation-defined? (Or is a particular
> implementation allowed to define its behavior for something which
> the standard calls "undefined behavior"?)[/color]

Undefined, and yes (but unlike proper implementation-defined behaviour,
such code may still launch a thermonuclear warhead if run on a DS-9000).

Richard
--
comp.lang.c.moderated - moderation address: clcm@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.

re: Testing for EOF in file with binary data

Kenneth Brody said:
[color=blue]
> Richard Heathfield wrote:[color=green]
>>
>> Joe Wright said:
>>[color=darkred]
>> > 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.[/color]
>>
>> The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
>> undefined behaviour.[/color]
>
> Is it undefined, or implementation-defined?[/color]

Undefined. I remember checking the Standard at the time I wrote it, so I'm
not going to check again. Feel free to look it up if you care enough.
[color=blue]
> (Or is a particular
> implementation allowed to define its behavior for something which
> the standard calls "undefined behavior"?)[/color]

Yes, absolutely - and that's where they make their money. We call such
extensions of the language "language extensions", and they are topical in
newsgroups devoted to discussing those implementations.

foo = fopen("bar.baz", "rt") is indeed a common extension.

And so is: foo = fopen("DD:bar", "rb recfm=f reclen=49");

These are not the droids you're looking for.

--
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: clcm@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.

re: Testing for EOF in file with binary data

Kenneth Brody wrote:[color=blue]
> Richard Heathfield wrote:[color=green]
> >
> > Joe Wright said:
> >[color=darkred]
> > > 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.[/color]
> >
> > The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
> > undefined behaviour.[/color]
>
> Is it undefined, or implementation-defined? (Or is a particular
> implementation allowed to define its behavior for something which
> the standard calls "undefined behavior"?)[/color]

It's undefined in standard C, and implementations are allowed to
"define UB". Most if not all do that in at least some ways. (A common
example is "\e", which is UB in standard C.)
--
comp.lang.c.moderated - moderation address: clcm@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.

re: Testing for EOF in file with binary data

Kenneth Brody wrote:[color=blue]
> Richard Heathfield wrote:[color=green]
> > The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
> > undefined behaviour.[/color]
> Is it undefined, or implementation-defined? (Or is a particular
> implementation allowed to define its behavior for something which
> the standard calls "undefined behavior"?)[/color]

The C standard explicitly says that the behavior is undefined
when the mode argument is not one of those explicitly listed in
the standard.

In cases of undefined run-time behavior, conforming
implementations are free to do what they wish; in this
particular instance the most likely alternatives are:
(a) ignore the unrecognized "t";
(b) recognize "t" as an extension meaning "text mode"
(which has the same effect as (a));
(c) consider the unrecognized "t" as a bad
invocation and have fopen report failure;
(d) induce a controlled program termination,
preferably with a diagnostic as to the cause;
(e) do something unplanned that might vary from
one moment to the next.
--
comp.lang.c.moderated - moderation address: clcm@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.

re: Testing for EOF in file with binary data

Kenneth Brody wrote:[color=blue]
> Richard Heathfield wrote:[color=green]
>> Joe Wright said:
>>[color=darkred]
>>> 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.[/color]
>> The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
>> undefined behaviour.[/color]
>
> Is it undefined, or implementation-defined? (Or is a particular
> implementation allowed to define its behavior for something which
> the standard calls "undefined behavior"?)[/color]

Implementations are allowed to define behaviour for instances of
undefined behaviour.
--
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: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> Greetings!
>
> I am working on a C app that needs to read print files generated by lp[/color]

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.
[color=blue]
> 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?[/color]

<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: clcm@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.

re: Testing for EOF in file with binary data

Richard Heathfield <invalid@invalid.invalid> writes:
[...][color=blue]
> These are not the droids you're looking for.[/color]

These are not the droids we're looking for.

--
Keith Thompson (The_Other_Keith) kst-u@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: clcm@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.

re: Testing for EOF in file with binary data

2006-06-03 <clcm-20060602-0013@plethora.net>, Harald van D?k wrote:[color=blue]
> Kenneth Brody wrote:[color=green]
>> Richard Heathfield wrote:[color=darkred]
>> >
>> > 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.[/color]
>>
>> Is it undefined, or implementation-defined? (Or is a particular
>> implementation allowed to define its behavior for something which
>> the standard calls "undefined behavior"?)[/color]
>
> It's undefined in standard C, and implementations are allowed to
> "define UB". Most if not all do that in at least some ways. (A common
> example is "\e", which is UB in standard C.)[/color]

A.6.5.15 Additional stream types and file-opening modes

Additional mappings from files to streams may be supported (§4.9.2),
and additional file-opening modes may be specified by characters
appended to the mode argument of the fopen function (§4.9.5.3).

and, from 4.9.5.3 (the fopen function)

The argument mode points to a string beginning with one of the
following sequences:/103/

103. Additional characters may follow these sequences.
--
comp.lang.c.moderated - moderation address: clcm@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.

re: Testing for EOF in file with binary data

Kenneth Brody wrote:[color=blue]
> Richard Heathfield wrote:[color=green]
>> Joe Wright said:
>>[color=darkred]
>>> 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.[/color]
>> The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
>> undefined behaviour.[/color]
>
> Is it undefined, or implementation-defined? (Or is a particular
> implementation allowed to define its behavior for something which
> the standard calls "undefined behavior"?)[/color]

Implementations are allowed to define behaviour for instances of
undefined behaviour.
--
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: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> Greetings!
>
> I am working on a C app that needs to read print files generated by lp[/color]

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.
[color=blue]
> 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?[/color]

<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: clcm@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.

re: Testing for EOF in file with binary data

David Warner wrote:[color=blue]
> Greetings!
>
> I am working on a C app that needs to read print files generated by lp[/color]

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.
[color=blue]
> 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?[/color]

<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: clcm@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.

re: Testing for EOF in file with binary data

Kenneth Brody wrote:[color=blue]
> Richard Heathfield wrote:[color=green]
>> Joe Wright said:
>>[color=darkred]
>>> 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.[/color]
>> The fopen function has no "rt" mode. Opening a file in "rt" mode invokes
>> undefined behaviour.[/color]
>
> Is it undefined, or implementation-defined? (Or is a particular
> implementation allowed to define its behavior for something which
> the standard calls "undefined behavior"?)[/color]

Implementations are allowed to define behaviour for instances of
undefined behaviour.
--
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: clcm@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.