Re: __attribute__((warn_unused_result)) for NetBSD?

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

> In article <[email protected]>,
> Thor Lancelot Simon  <[email protected]> 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