Re: Strange fread(3) Behavior with CVS glibc

[Chris Ahna]

On Mon, Feb 04, 2002 at 05:34:38PM +0100, Andreas Jaeger wrote:
> > I'm seeing some strange behavior from fread(3) with the CVS (mainline)
> > glibc.  fread(3) is returning zero whenever the first character it reads
> > is 0xff.  It doesn't seem to react like this to 0xff characters appearing
> > anywhere else.  I'm seeing this on both ia64-unknown-linux and i686-
> > pc-linux-gnu.  This is breaking GNU ld on my i686-pc-linux-gnu box.
> 
> The broken ld has been discussed already, this is a bug in ld that I
> fixed some days ago - but we also changed glibc again.  So updating
> might fix your problem.  If not, please write a small program that
> shows the behaviour and send it here.

I don't think this is the same problem since I was using binutils and
glibc snapshots taken after the associated fixes were made.  Here's a
testcase that shows the problem I'm seeing:

test.c:

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv)
{
        FILE *f = fopen ("ones", "r");
        char buf[64];
        int nread;

        nread = fread (buf, 1, 64, f);

        printf ("Read %d 1 byte chunks.\n", nread);

        fclose (f);

        return 0;
}

where "ones" is a file containing 64 0xff characters (I've attached
this).

Using glibc 2.2.4 I get

        > ./test
        Read 64 1 byte chunks.

and with the CVS glibc I get

        > ./test
        Read 0 1 byte chunks.

On my i686-pc-linux-gnu system, ld attempts an fread(3) at a file
position containing a 0xff character when processing crtbegin.o.
This causes the same change in behavior shown in the above testcase.

Thanks,

Chris

ones
Description: Text document