Patrick J. LoPrest writes:
> Failures happen. They can happen on write(), they can happen on
> close(), and they can happen on any system call for which the API
> allows it. There is no difference! Your application either deals
> with them and is correct or fails to deal with them and is broken.
>
> If the API allows an error return, you *must* check for it, period.
> This includes "impossible" errors. You may think it is impossible for
> gettimeofday() to return an error in some case, but if it ever did,
> you should darn well want to know about it right away.
>
> If you are that convinced that close() can not return an error in your
> particular application (e.g., because you "know" you are using a local
> disk, or the file descriptor is read-only), then treat such errors
> like assertion failures. Because that is what they are.
>
> Checking system calls for errors, always, is fundamental to writing
> reliable code. Failing to check them is shoddy and amateurish
> programming. It is amazing that so many people would argue this
> point. Then again, maybe not, given how bad most software is...
You check printf() and fprintf() then? Like this?
///////////////////////////////////////////
void err_print(int err){
const char *msg;
int rc;
msg = strerror(err);
if(!msg) err_print(errno);
do{
rc = fprintf(stderr,"Problem: %s\n",msg);
}while(rc<0 && errno==EINTR);
if(rc<0) err_print(errno);
}
///////////////////////////////////////////
Get off your high horse.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:28 EST