Date: Wed, 22 Nov 2000 14:25:34 +0200 (SAST) From: Robert Nordier <rnordier@nordier.com> To: dcs@newsguy.com (Daniel C. Sobral) Cc: drosih@rpi.edu (Garance A Drosihn), hackers@FreeBSD.ORG Subject: Re: fclose vs ferror (from libc/getcap) Message-ID: <200011221225.OAA04292@siri.nordier.com> In-Reply-To: <3A1B66A3.D29C8565@newsguy.com> from "Daniel C. Sobral" at Nov 22, 2000 03:24:35 PM
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel C. Sobral wrote:
> Garance A Drosihn wrote:
> >
> > >Undefined behavior means anything goes. On a standard, it means the
> > >behaviour is implementation-defined (which may be undefined or not).
While not disagreeing with what I think Daniel means: at least in the
C Standard itself, "undefined behavior" and "implementation-defined
behavior" are kept carefully separate. A quote from X3J11's Rationale
document probably addresses the crux of the issue Garance raised,
though:
Undefined behavior gives the implementor license not to catch
certain program errors
> > 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.
>
> He said he would _tend_ to expect it to work. To me, that means the code
> is dubious, but is likely to work.
Garance himself writes, two messages back:
The thing with ferror is that it will generally "work" after
the fclose, although the value it returns might not be the
right (pre-close) value.
and I really meant something very similar. Though I'd probably go a
bit further and say -- knowing how ferror is likely to be implemented
-- the most probable result of invoking it after fclose would be a
failure to detect that an I/O error had occurred. For "hairy old C
code", that "works" about as much as I'd expect it to.
> > > 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.
>
> 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]
and elsewhere goes on to describe a stream as, for example
an ordered sequence of characters [7.9.2]
so I think it's fairly clear that a stream is not what (FILE *)
points at.
I doubt that the SUS would intentionally deviate on such a fundamental
point.
--
Robert Nordier
rnordier@nordier.com
rnordier@FreeBSD.org
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?200011221225.OAA04292>