Fgetc returns the wrong character (0a -> 0d)

[Georg Troxler]

I try to parse a file. When I read a int with fgetc(f) I get the wrong
result.
When I open the file with a Editor I see clearly the character should be 0d.
In the Memory of f (buffer) it is 0a. What the Hell is going wrong here. I
calculated the offset und figured the chars are the same position. Memory
Error is not possible since I look at the Memory just after the Buffersize
was 0. (Means the MSL just filled the Buffer again). When I change the 0d to
0a it does exactly the opposite.

 

[Alexander Bartolich]

begin followup to Georg Troxler:

I try to parse a file. When I read a int with fgetc(f) I get the
wrong result. When I open the file with a Editor I see clearly the
character should be 0d.

Unix uses \xA for a line feed.
DOS, Windows, NT and OS/2 use \xD\xA for a line feed.
MacOS <= 9 uses \xD for a line feed.

Some implementations on these platforms convert the OS specific line
feed into "\xA" on input. See your vendors documentation for the
keywords 'binary mode'. Probably specifing character 'b' to argument
mode of mode should do.

 

[P.J. Plauger]

I try to parse a file. When I read a int with fgetc(f) I get the wrong
result.
When I open the file with a Editor I see clearly the character should be 0d.
In the Memory of f (buffer) it is 0a. What the Hell is going wrong here. I
calculated the offset und figured the chars are the same position. Memory
Error is not possible since I look at the Memory just after the Buffersize
was 0. (Means the MSL just filled the Buffer again). When I change the 0d to
0a it does exactly the opposite.

Open the file as binary and you won't get this mapping that
seems to irritate you.

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

 

[Darrell Grainger]

I try to parse a file. When I read a int with fgetc(f) I get the wrong
result.
When I open the file with a Editor I see clearly the character should be 0d.
In the Memory of f (buffer) it is 0a. What the Hell is going wrong here. I
calculated the offset und figured the chars are the same position. Memory
Error is not possible since I look at the Memory just after the Buffersize
was 0. (Means the MSL just filled the Buffer again). When I change the 0d to
0a it does exactly the opposite.

How was the file opened? If you open it as a text file, i.e. "r" rather
than "rb", then what is stored on the system and how it comes in the
stream can be different.

Try opening the file as binary and see if that solves your problem.

 

[Emmanuel Delahaye]

I try to parse a file. When I read a int with fgetc(f) I get the wrong
result.
When I open the file with a Editor I see clearly the character should be
0d. In the Memory of f (buffer) it is 0a

Open the file in binary mode ("rw") for a raw process of the data.

 

[August Derleth]

Open the file in binary mode ("rw") for a raw process of the data.

ITYM "rb". "rw" implies read/write, which I don't think is implemented
by the standard library.

 

[Emmanuel Delahaye]

ITYM "rb". "rw" implies read/write, which I don't think is implemented
by the standard library.

Your are correct, and I was dumb. Apologies.

 

[Emmanuel Delahaye]

Open the file in binary mode ("rw") for a raw process of the data.

Of course, I meant "rb".

 

[Dan Pop]

ITYM "rb". "rw" implies read/write, which I don't think is implemented
by the standard library.

It is implemented, but it's spelled "r+" or "w+" (the former preserves
the contents of the file upon opening, the latter wipes it out).

Dan