[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    [W:4.032 / U:0.372 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site