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.

--
Für Google, Tux und GPL!

[P.J. Plauger]

"Georg Troxler" <ge***********@yaksoft.com> wrote in message
news:BC399A40.4B47%ge***********@yaksoft.com...

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]

On Sun, 25 Jan 2004, Georg Troxler wrote:

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.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov

[Emmanuel Delahaye]

In 'comp.lang.c', Georg Troxler <ge***********@yaksoft.com> wrote:

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.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[August Derleth]

Emmanuel Delahaye wrote:

In 'comp.lang.c', Georg Troxler <ge***********@yaksoft.com> wrote:

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.

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

--
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.

[Emmanuel Delahaye]

In 'comp.lang.c', August Derleth <se*@sig.now> wrote:

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.

Your are correct, and I was dumb. Apologies.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Emmanuel Delahaye]

In 'comp.lang.c', Emmanuel Delahaye <em**********@noos.fr> wrote:

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

Of course, I meant "rb".

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Dan Pop]

In <5b******************@fe02.usenetserver.com> August Derleth <se*@sig.now> writes:

Emmanuel Delahaye wrote:

In 'comp.lang.c', Georg Troxler <ge***********@yaksoft.com> wrote:

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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de