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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
