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 <stdio.h>
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 = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute or [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
