[lkml]   [2002]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: close return value
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);
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean