Says who? POSIX defines all kinds of behaviors as implementation dependent.
This includes things like freeing freed pointers, closing closed files, etc.
>This says that you can make the VALUE of the pointer anything youwish after
the
>file was closed. Therefore you can leave its VALUEalone or you can change
it to
>NULL (as some do), or you can do anything
>It says nothing about attempting to write data to a closed file. Some
>implementations change the value of the pointer to NULL when the fileis
closed,
>this allows one to detect user program bugs by seg-faultingif an attempt is
made
>to use that pointer again.
>This does not fix the observed behavior unless a close(fd) results inany
>associated FILE object being set to NULL as well.
Really? Name one OS that sets "any asociated" FILE* to NULL on a close(fd)
function. That I'd like to see:
FILE *a, *b, *c, *d;
a = b = c = d = fopen("NotLikely.IMO", "w");
close(fileno(a)); /* or even fclose(a); */
/* now a b c and d are NULL, right? */
>RETURN VALUES
> printf(), fprintf(), and sprintf() return the number of
> characters transmitted, or return a negative value if an error was
>encountered.
Well, I'm no standards expert, but I always understood the return value from
these functions to refer to the number of characters *formatted* or -1 if
there was a formatting error.
Case in point: stdio is buffered. Should every call to fprintf check (for
example) that there is enough disk space free to flush the buffer (with a
kernel round trip to find out)? Kinda defeats the purpose of buffering,
don't it?
I suppose that would be possible in a world where performance didn't matter,
but I will take the undefined behavior, thanks. Writing to closed files is
an application bug, not a library bug.
Cheers,
Ken