From owner-freebsd-hackers Wed Nov 22 9:42:19 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 60DF837B4C5 for ; Wed, 22 Nov 2000 09:42:15 -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 MAA585902; Wed, 22 Nov 2000 12:41:58 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200011221225.OAA04292@siri.nordier.com> References: <200011221225.OAA04292@siri.nordier.com> Date: Wed, 22 Nov 2000 12:41:56 -0500 To: Robert Nordier , dcs@newsguy.com (Daniel C. Sobral) From: Garance A Drosihn Subject: Re: fclose vs ferror (from libc/getcap) Cc: hackers@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:25 PM +0200 11/22/00, Robert Nordier wrote: >Daniel C. Sobral wrote: > > > Garance A Drosihn wrote: > > > In the section I quoted from unix spec, "stream" refers to the >> > variable passed to fclose (though that isn't obvious, because I >> > didn't copy the formatting). ferror certainly does access that >> > variable. >> > > MMmmmm. That's a dubious interpretation. The variable is a handle > > to the stream, not the stream itself. Are you sure of the SUS > > wording? > >The original ISO standard defines "FILE" as > > an object capable of recording all the information needed to > control a stream [7.9.1] > > [...skipping...] > >I doubt that the SUS would intentionally deviate on such a >fundamental point. I've replied to both Robert and Daniel with (I think) the exact section of SUS that I was quoting. I didn't want to send a message with all those formatting characters to the mailing list, because I really don't know how well that would work out... For others who might be curious, I was not saying that "the concept of a stream" refers to the variable sent to fclose. I meant that in the exact section I was quoting, that word 'stream' is in italics, and thus it refers to the variable 'stream' which SUS used in the synopsis of fclose. Eg: #include int fclose(FILE *stream); ------ (the underlined 'stream' was written in italics), and: After the call to fclose(), any use of stream ------ ------ causes undefined behaviour. (where both fclose and stream are in italics in the section I was quoting from). Their description for fclose does also use the phrase 'a stream' (with no italics) in the same way everyone else has been using it. - - - - - - Also for the curious, here is the "resolution" of my bug report as it was sent to redhat: + libc is allowed to start nethack, format your disks, + whatever it wants in this case. + + The fact that it magically works on some other system + means nothing, the results of such operation are undefined. + glibc in ferror has to acquire lock of the stream in + question first (thus writes into memory). Perhaps other + systems either don't care about multiple threads (and do + no locking) or slow each operation down (by checking + if the file descriptor is valid at the start of every + single routine). + + You can turn some of such checks by recompiling glibc + with IO_DEBUG, but as such checks just catch some cases + and can pass even on invalid FILE descriptors and also + slow things down, they are not enabled by default. + + So think about ferror on fclosed FILE as if you put + random garbage into that memory area yourself. It is interesting that they talk about acquiring a lock for the stream in question first. As freebsd does more with SMP and threads, will freebsd need to do similar locking? They are also trumpeting the fact that the behavior in this case is "undefined", and thus they feel there is no problem with the fact that the call to ferror trashes random locations in memory and will trigger very obscure bugs which are no where near the "real bug" (ie, the ferror). All very well. Everyone gets to use the term "undefined behavior" to justify that no changes should be made to there version fclose or ferror. All I'm saying is that this leaves the person porting "hairy old C code" in a mighty unpleasant position. This fclose/ferror combination is a fairly easy mistake to miss (particularly since it does work on freebsd), but it might be lethal on other platforms. And if it is lethal, you will get no sympathy once you do track it down. Here I lost 30 hours tracking down a bug in code I did not write in the first place, and everyone's attitude seems to be that it's my fault for wanting to port some C code to multiple platforms. So, for those hackers who do port C code, put this combination on the list of things you should lookout for. -- --- 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