Re: __attribute__((warn_unused_result)) for NetBSD?

[James Chacon <jmc%netbsd.org@localhost>]

On Sep 14, 2008, at 7:30 PM, Christos Zoulas wrote:

> In article <20080915000724.GA17012%panix.com@localhost>,
> Thor Lancelot Simon  <tls%rek.tjls.com@localhost> wrote:
> > On Sun, Sep 14, 2008 at 07:53:55PM -0400, der Mouse wrote:
> > > > > Why?  IMO Not checking for return value of all these functions as
> > > > > well as close fclose etc. is VERY dangerous.
> > > > Please, explain to me what exactly you intend to do to handle an
> > > > error return from close().
> > >
> > > I didn't write that.  But the answer seems pretty obvious: report  
> > > it to
> > > wherever is appropriate for errors on the file in question.
> > >
> > > Typically an error from close() will be something like a delayed- 
> > > write
> > > I/O error, something the file writer quite likely wants to hear  
> > > about.
> >
> > You might be able to report it to the user.  However, it's among  
> > those
> > errors for which, I think, if you consider actual use cases  
> > carefully,
> > it is least likely that you can actually take corrective action.   
> > After
> > all, you've closed the file.  Across a close, all kinds of normal  
> > Unix
> > I/O semantics you might expect are simply not going to hold...
>
> For the 2 errno entries listed in close(2):
>
> EBADF: Programming error.
> EINTR: User could re-try.
>
> Both sound nice to report back.

Lots of existing code does this at startup:

for (i=0; i<255; i++)
        close(i);

Or something similar. I'm not claiming that's valid for a lot of  
reasons but it is a common idiom and yes it's deliberately ignoring  
the return value there on purpose obviously.

In general EBADF is meaningless on close. Assuming you were catching  
errors in read/write already you would have already noticed using the  
wrong fd. If you weren't catching errors there, reporting a warning  
for close will just duplicate the ones we should be returning for those.

Isn't it only possible to get EINTR on non-blocking I/O? Otherwise  
isn't this an auto-restarted call?

Anyways, for the most part all common usages of close don't need  
warnings about missing the return value that I can see. Spitting lots  
of warnings for the common case makes the warning useless.

James