Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Nov 2000 01:08:06 -0500
From:      Garance A Drosihn <drosih@rpi.edu>
To:        "Daniel C. Sobral" <dcs@newsguy.com>
Cc:        Robert Nordier <rnordier@nordier.com>, hackers@FreeBSD.ORG
Subject:   Re: fclose vs ferror (from libc/getcap)
Message-ID:  <p04330100b641090d2474@[128.113.24.47]>
In-Reply-To: <3A1B5592.89A7BBE2@newsguy.com>
References:  <200011201020.MAA23349@siri.nordier.com> <p04330104b640abfaf13d@[128.113.24.47]> <3A1B5592.89A7BBE2@newsguy.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 2:11 PM +0900 11/22/00, Daniel C. Sobral wrote:
>Garance A Drosihn wrote:
>  >
>  > The "single Unix spec" says:
>>        After the call to fclose(), any use of stream causes
>>        undefined behavior.
>>
>>  FreeBSD's own man page for fclose says:
>>        [fclose returns 0 or EOF].  In either case, no further
>>        access to the stream is possible.
>>
>>  Neither of those indicate that anyone should "expect it to
>>  work", no matter what language they are programming in.  There
>>  is nothing in the description for ferror which implies that it
>>  is some magical exception to the above rules.
>
>Undefined behavior means anything goes. On a standard, it means the
>behaviour is implementation-defined (which may be undefined or not).

But if "anything goes", then that you can not expect it to
work; certainly not when porting to other platforms.

I am not saying that what freebsd does is wrong.  But Robert
said that "[that code is a silly thing], but if I was porting
some hairy old C code I'd tend to expect it to work."
It seems to me that if the behavior is explicitly undefined
then you can NOT expect much of anything when porting.

In any case, I did bug redhat about it (once I found the right
web page), as it is the implementation of fclose in glibc which
really caused all my headaches.  Someone has already replied,
at least to change the bug report from libc to glibc.

As for freebsd, I do hope to fix the specific code in getcap.c,
but I am not suggesting a change to fclose/ferror unless other
developers felt this was a problem (and obviously no one seems
to :-).  I did want to remark on it, in case other people USE
the combination of fclose followed by ferror, and then run into
mysterious problems when they port their code to other platforms.
I certainly did not enjoy tracking this down, and by mentioning
it here then maybe I'd save someone else some headaches.

>  And notice that ferror() is not an access to the stream.

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.
-- 

---
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p04330100b641090d2474>