EOF problem

[BH]

I'm doing a decryption prog which read a enc. file and decrypt it. However,
some of the encrypted text is the same as EOF and thus i cant read the text
that after it. What should i do?

I tried the getline and read.. but still cant work.. can anyone help me?

 

[osmium]

I'm doing a decryption prog which read a enc. file and decrypt it. However,
some of the encrypted text is the same as EOF and thus i cant read the text
that after it. What should i do?

I tried the getline and read.. but still cant work.. can anyone help me?

There is no EOF character. EOF is a *condition*, not a character, at least
in the context of a C++ program. Rethink your problem. The typical modern
computer has 256 character codes, none of which denote EOF.

 

[Arne Schmitz]

There is no EOF character.  EOF is a condition, not a character, at least
in the context of a C++ program.  Rethink your problem.  The typical
modern computer has 256 character codes, none of which denote EOF.

Well, if he uses a Windows compiler and opened the file in textmode (without
"b"-flag) using fopen(3), then he will stumble over EOF characters as they
existed in the legacy ASCII character set.

Posix ignores the "b"-flag and treats text- and binary files the same.

Cheers,

Arne

 

[David Harmon]

I'm doing a decryption prog which read a enc. file and decrypt it. However,
some of the encrypted text is the same as EOF and thus i cant read the text
that after it. What should i do?

I tried the getline and read.. but still cant work.. can anyone help me?

You must open the file in binary mode using the ios::binary openflag
value. See e.g.:
http://groups.google.com/[email protected]

 

[Kevin Goodsell]

osmium schrieb:




Well, if he uses a Windows compiler and opened the file in textmode (without
"b"-flag) using fopen(3), then he will stumble over EOF characters as they
existed in the legacy ASCII character set.

Maybe, but as the man said, (C++) EOF is a condition, not a character.
You cannot find (C++) EOF unless you are and the actual end of the file.
Finding ASCII EOF does not cause (C++) EOF. Well, it could, but that
would be the implementation's fault. Obviously if that's the case he
would need to decide on a solution, such as 1) use binary mode, or 2)
make your text files valid for the host system (remove EOF characters
that don't actually indicate EOF).

-Kevin

 

[David Harmon]

On Sun, 18 Apr 2004 19:02:07 GMT in comp.lang.c++, Kevin Goodsell

Finding ASCII EOF does not cause (C++) EOF. Well, it could, but that
would be the implementation's fault.

It is perfectly within the range of allowable behavior for text mode.
And might even have a justifiable reason in some case(*).
If you do not like it, use binary mode like you are supposed to.

(*)The origin of this nonsense was an ancient filesystem that did not
store the exact file size, so text files needed a internal mark at the
end after the final character. This was not C++'s fault or even C's
fault.

 

[Kevin Goodsell]

On Sun, 18 Apr 2004 19:02:07 GMT in comp.lang.c++, Kevin Goodsell



It is perfectly within the range of allowable behavior for text mode.

Yes, I didn't mean that the implementation would be in error. Just that
it would be a somewhat unusual implementation, or at least behaving in a
rather unexpected (though not wrong) way.

-Kevin

 

[David Harmon]

It is perfectly within the range of allowable behavior for text mode.

Yes, I didn't mean that the implementation would be in error. Just that
it would be a somewhat unusual implementation, or at least behaving in a
rather unexpected (though not wrong) way.[/QUOTE]

More prevalent than any of us might wish.

 

[Jack Klein]

Well, if he uses a Windows compiler and opened the file in textmode (without
"b"-flag) using fopen(3)

[snip]

"fopen(3)" is, of course, a constraint violation in standard C++,
since the prototype for fopen() is:

FILE *fopen(const char *filename, const char *mode);

===

Yes, I know what you mean by "fopen(3)", but it's a reference to a
system-specific utility for viewing "man pages", nothing to do with C
or C++ or the definition of the function. And it's likely to confuse
newbies, most particularly those working on a Windows platform.