From owner-freebsd-hackers Sun Nov 19 17:28: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 4236837B479 for ; Sun, 19 Nov 2000 17:27:59 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id UAA409210 for ; Sun, 19 Nov 2000 20:27:58 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sun, 19 Nov 2000 20:27:56 -0500 To: hackers@FreeBSD.org From: Garance A Drosihn Subject: fclose vs ferror (from libc/getcap) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As mentioned in pr bin/22965, I stumbled across a bug in libc/gen/getcap.c when compiling it under other platforms. The basic problem is some code which does: (void)fclose(pfp); if (ferror(pfp)) { ...do stuff... } I find it surprising that the above works under FreeBSD. (not only that, it seems to work OK under several other OS's too). The fclose is supposed to throw away the stream, but the ferror (apparently) still works with that pointer. The PR includes a patch for getcap.c (which is just to use the result from fclose to determine if an error occurred), but I also wonder if we should do something so that this combination would ALWAYS fail. It seems to me that fclose should clear out whatever fields that ferror is using for sanity-checking, and ferror should always return an errno of 'bad parameter', or something like that. Or is there some reason that we DO want ferror to work on streams which have already been closed? -- --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message