> When was the last time you checked the return code from fclose()?  You 
> do realise that if fclose() fails (on writing) you could actually lose 
> data?

ac> Regarding fclose the C standard says, "The fclose function
returns zero if 
ac> the stream was successfully closed, or EOF if any errors were detected."

ac> If fclose returns EOF, is the file closed or still open?  

From reading the rest of the standard, stream being disassocatied
from the file, buffers deallocated etc, I would say that after a
call to fclose(), the FILE pointer is no longer in a fit state to
be used.  The stuff in fclose says that all this stuff is done, it
doesn't say "if a problem is found attempting to write the data,
you instead do xyz, and the file will remain open".  Therefor, the
file pointer is totally unusable after a call to fclose().  The
only thing that happens in the case of detected errors is the
return code change, not the function of fclose().  Compare that to
say if you go free(NULL), it tells you about the changed logic if
the parameter is NULL.

ac> If errors are 
ac> detected the file may well be closed by fclose regardless.  The standard is 
ac> ambiguous here.

I don't think it is.  You are taking one minor point in the return
code and attempting to apply it to the previous description.
Compare that to scanf() which says exactly what happens if you get
an error whilst parsing.

> The best argument against this "committee never works" theory is the 
> ANSI C standard.  It's faultless.  BFN.  Paul.

ac> Ummm.

What that committee produced is the best standard I've ever seen.
BFN.  Paul.
@EOT:

---