Date: Thu, 07 Aug 2008 18:58:17 +0200 From: Gabor Kovesdan <gabor@kovesdan.org> To: "Sean C. Farley" <scf@FreeBSD.org> Cc: fjoe@FreeBSD.org, hackers@FreeBSD.org Subject: Re: strange issue reading /dev/null Message-ID: <489B29A9.1090609@kovesdan.org> In-Reply-To: <alpine.BSF.1.10.0808071150460.2133@thor.farley.org> References: <489B0ACD.80008@kovesdan.org> <alpine.BSF.1.10.0808071058020.1056@thor.farley.org> <489B22BD.5050109@kovesdan.org> <alpine.BSF.1.10.0808071150460.2133@thor.farley.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean C. Farley ha scritto:
> On Thu, 7 Aug 2008, Gabor Kovesdan wrote:
>
>> Sean C. Farley ha scritto:
>>> You are testing c which has not been set. It works OK if you set c
>>> then do the test:
>>>
>>> + c = fgetc(f);
>>> if (c != EOF)
>>> - printf("%c\n", fgetc(f));
>>> + printf("%c\n", c);
>> Yes, you are right, this is what I meant, I'm just a bit
>> disorganised....
>> Thanks!
>
> You are welcome.
>
> Actually, what I found odd was that the base gcc did not warn about
> using an uninitialized variable using -Wall.
>
> Obviously, test fopen() and fgetc() return codes correctly as others
> have noted. I just assume you were not in your test program.
Actaually, I wanted to track down why BSD grep echoed the y with the
diaresis when I executed grep . </dev/null that's why I wrote this test
program, but I should have taken more care. As a result, I could find
the bug in grep, it was not enough to check !feof() in the for
iteration, I needed to check for EOF right after calling fgetc() and
break if it matched.
Gábor
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?489B29A9.1090609>