question about proton error philosophy

2013-09-16 Thread Michael Goulish

I was expecting errno inside the messenger to be reset to 0 at the end of any 
successful API call.

It isn't: instead it looks like the idea is that errno preserves the most 
recent error that happened, regardless of how long ago that might be.

Is this intentional?

I am having a hard time understanding why we would not want errno to always 
represent the messenger state as of the completion of the most recent API call.


I would be happy to submit a patch to make it work this way, and see what 
people think - but not if I am merely exhibiting my own philosophical 
ignorance here.




Re: question about proton error philosophy

2013-09-16 Thread Michael Goulish

No, you're right.

errno is never set to zero by any system call or library function
( That's from Linux doco. )

OK, I was just philosophically challenged.
I think what confused me was the line in the current Proton C doc (about errno) 
that says an error code or zero if there is no error.
I'll just remove that line.

OK, I withdraw the question.


( I still don't like this philosophy, but the whole world is using it, and the 
whole world is bigger than I am... )


  

- Original Message -
Do other APIs reset the errno?  I could have sworn they didn't.

On Mon, Sep 16, 2013 at 12:01 PM, Michael Goulish mgoul...@redhat.com wrote:

 I was expecting errno inside the messenger to be reset to 0 at the end of any 
 successful API call.

 It isn't: instead it looks like the idea is that errno preserves the most 
 recent error that happened, regardless of how long ago that might be.

 Is this intentional?

 I am having a hard time understanding why we would not want errno to always 
 represent the messenger state as of the completion of the most recent API 
 call.


 I would be happy to submit a patch to make it work this way, and see what 
 people think - but not if I am merely exhibiting my own philosophical 
 ignorance here.





-- 
Hiram Chirino

Engineering | Red Hat, Inc.

hchir...@redhat.com | fusesource.com | redhat.com

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo


Re: question about proton error philosophy

2013-09-16 Thread Darryl L. Pierce
On Mon, Sep 16, 2013 at 12:33:29PM -0400, Hiram Chirino wrote:
 Do other APIs reset the errno?  I could have sworn they didn't.

Successful system calls and library functions never reset errno to 0, so
this variable may have a nonzero value as a consequence of an error from
a previous call. Furthermore, SUSv3 permits a successful function call to
set errno to a nonzero value (although few functions do this). Therefore,
when checking for an error, we should always first check if the function
return value indicates an error, and only then examine errno to determine
the cause of the error. - The Linux Programming Interface, pg 49.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpEFRS5MxPIW.pgp
Description: PGP signature


Re: question about proton error philosophy

2013-09-16 Thread Hiram Chirino
Do other APIs reset the errno?  I could have sworn they didn't.

On Mon, Sep 16, 2013 at 12:01 PM, Michael Goulish mgoul...@redhat.com wrote:

 I was expecting errno inside the messenger to be reset to 0 at the end of any 
 successful API call.

 It isn't: instead it looks like the idea is that errno preserves the most 
 recent error that happened, regardless of how long ago that might be.

 Is this intentional?

 I am having a hard time understanding why we would not want errno to always 
 represent the messenger state as of the completion of the most recent API 
 call.


 I would be happy to submit a patch to make it work this way, and see what 
 people think - but not if I am merely exhibiting my own philosophical 
 ignorance here.





-- 
Hiram Chirino

Engineering | Red Hat, Inc.

hchir...@redhat.com | fusesource.com | redhat.com

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo