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>