Re: Problems with fgetc on Linux - Is this a Bug?

["Albert E. Whale" <aewhale at access dot hky dot com>]

Thank you!

Works perfectly now.  Hind sight is always 20/20.

Thanks to everyone!



Anjul Srivastava wrote:
> 
> 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

-- 
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