Problems with fgetc on Linux - Is this a Bug?

Anjul Srivastava anjul.srivastava@sanchez.com
Thu Feb 17 13:18:00 GMT 2000


Hi,

Please change your code to make the variable: "ch" to be an 'int' instead of
a 'char'

This is a coding bug, rather than a bug in Linux or gcc.

I doubt if your code worked fine even on Ultrix with "ch" declared to be a
'char'. Are you sure that the code is exactly the same as the one that you
ran on DEC Ultrix?

To explain what is happening: fgetc( FD ) returns 255 upon reading 'ff'.
This 255 is assigned to the char ch whereupon it becomes a -1. This -1 is
promoted to an int and remains a -1 which causes the comparison to EOF to
succeed because EOF happens to be #defined as a -1. When ch is an int, the
255 remains a 255 and does not become a -1.

Anjul.

-----Original Message-----
From: Albert E. Whale [ mailto:aewhale@access.hky.com ]
Sent: Thursday, February 17, 2000 3:59 PM
To: GCC Mailing List
Subject: Problems with fgetc on Linux - Is this a Bug?


I could use a little help.

I'm converting software which was developed on DEC Ultrix to run on
Linux.  It works great on Ultrix, and I'm not sure if I've found a bug
in Linux or not.


The code fragment looks like this:

    while ( n < len ) {

        if (( ch = fgetc( FD ) ) == EOF ) {
            if ( n>1)
                return( n );
            else
                return( EOF );
            }
        line[n++] = ch;
        }

This fragment works great on Ultrix, on Linux ;-(  On Linux, I get 12
bytes of data.  So I checked the information in the file, and came up
with the following output from `od`.


[root@Elvis newtolls]# od -N 750 -t x 289.122
0000000 01000015 00c100fe f0000001 0004caff
0000020 80000000 ffffffff ffffffff ffffffff
0000040 ffffffff ffffffff ffffffff ffffffff
*
0001000 fff00000 00070002 00000000 45000000
0001020 00aa0000 4c833c83 00004c04 4c040c00
0001040 0c000000 007c2000 0000000c 0c000000
0001060 00007c00 00000000 3c616235 4c032715
0001100 12100000 000c000c 0c000000 1c001c00
0001120 007c2001 aa00003c 001c0000 004c046c
0001140 040c0000 0000004c 7c20000c 000c0000
0001160 0c0c0000 0c000c0c 62354c72 001c2c48
0001200 75584c72 35156c61 00009c20 001c0102
0001220 aa000047 001c0040 004c046c 040c0000
0001240 0000004c 7c20000c 000c0000 1c0c0000
0001260 0c000c0c 64354c72 001c5c44 11564c72
0001300 37155c83 00000c12 020c0000 7c20005c
0001320 0c293715 3c000c00 00aa0000 6c001c00
0001340 00004c04 4c040c00 0c000000 00002000
0001356

It appears that the 0xFF code is being interpreted as the EOF marker.


Any suggestions?



-- 
Albert E. Whale       aewhale@hky.com
http://www.hky.com/aewhale.html
------------------------------------------------------------------
Sr. Database, Internet and Unix Systems Consultant

Pennsylvania Parenthood Initiative - PAPI
http://www.geocities.com/Heartland/4688/papi.htm
The Father's Rights Network - http://www.hky.com/frn/frnhome.html
Parents without Partners - Past President
Co-Founder of The Purple Heart Foundation


More information about the Gcc mailing list