On Mon, 2013-09-16 at 13:23 -0400, Rafael Schloming wrote: > FYI, as of 0.5 you should be able to use > pn_messenger_error(pn_messenger_t > *) to access the underlying error object (pn_error_t *) and clear it > if an > error has occurred. >
Making the application clear errno is pretty standard Unix practice too. I think the justification is that only the application can decide when a given error has been "resolved", so only the application should clear errno. The library should not "hide" an error that the application has not explicitly indicated it is done with. If library functions call each other etc. the risk of losing an error is too great if they all start by assuming "all OK". It it philosophically questionable but C is not a very philosophical language. > --Rafael > > On Mon, Sep 16, 2013 at 12:40 PM, Michael Goulish < > [email protected]>wrote: > > > > > 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 < > > [email protected]> > > 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. > > > > [email protected] | fusesource.com | redhat.com > > > > skype: hiramchirino | twitter: @hiramchirino > > > > blog: Hiram Chirino's Bit Mojo > >
