From owner-freebsd-hackers  Wed Nov 22  6:33:53 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from siri.nordier.com (c3-dbn-54.dial-up.net [196.33.200.54])
	by hub.freebsd.org (Postfix) with ESMTP id B85D437B4CF
	for <hackers@FreeBSD.ORG>; Wed, 22 Nov 2000 06:33:42 -0800 (PST)
Received: (from rnordier@localhost) by siri.nordier.com (8.9.3/8.6.12) id OAA04292; Wed, 22 Nov 2000 14:25:34 +0200 (SAST)
From: Robert Nordier <rnordier@nordier.com>
Message-Id: <200011221225.OAA04292@siri.nordier.com>
Subject: Re: fclose vs ferror (from libc/getcap)
To: dcs@newsguy.com (Daniel C. Sobral)
Date: Wed, 22 Nov 2000 14:25:34 +0200 (SAST)
Cc: drosih@rpi.edu (Garance A Drosihn), hackers@FreeBSD.ORG
In-Reply-To: <3A1B66A3.D29C8565@newsguy.com> from "Daniel C. Sobral" at Nov 22, 2000 03:24:35 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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