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).
>
> But if "anything goes", then that you can not expect it to
> work; certainly not when porting to other platforms.
Sure enough. The behavior of any function on a closed FILE* is not
defined by standards.
> 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.
> > 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?
--
Daniel C. Sobral (8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"All right, Lieutenant, let's see what you do know. Whatever it is,
it's not enough, but at least you haven't done anything stupid yet."
"I've hardly had time, sir."
"There's a naive statement."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
