Problem locking serial device

[Blankman]

Rich, yes, on success a function is allowed to alter errno, but to the best of my knowledge there are no values for errno for the functions used in aurora that do not indicated that some sort of a problem occurred. But if a function returns success but errno has been set to something, I want to know about it. That's an "or" not an "and".

And, in those instances I am checking for the unexpected, if something is returned that I do not expect, I want to know about it. If the function returns a negative then errno should be a non-zero number. If the function returns a 0 (zero) errno should be 0 also, if it isn't I want to look into why. My oversight in two places was that I didn't first initialize errno to 0.

I am thorough and meticulous, I check for everything I can think of and that of course is still not all encompassing.

Where I used to work we had a programer that prided himself on being a Mensa member and knew everything so he only checked for error codes returned that he thought could be returned, anything outside of what he thought could be returned he considered success. Well one day an error was returned that he thought would never be returned and the program just kept chugging along. For quite a while until someone noticed anomalies in reports. Turns out the code landed up populating 500,000 rows into a production DB that was used for FDA reporting. Needless to say that had to be cleaned up creating a lot of work.

My philosophy is that if something occurs that is not expected to occur, stop right there and evaluate why it occurred. That is what those checks are doing, and it worked. errno is not expected to be non-zero at that point when the function returns zero so that will be corrected even though it was caused by the code itself. So the error is that errno is not initialized and to me that is an error in the code that will be addressed.

*If* in the future a function returns success but also returns a non-zero errno by design I will be able to evaluate it and if deemed OK then code an exception. Meanwhile, it won't possibly be sitting there chugging along fat dumb and happy while corrupting data that then has to be cleaned up or worse yet is lost for an extended period of time because an exception wasn't thrown.

It brought to light that this distro operates differently then others, no big deal. Would have never come to light even here had it not been for my oversight.

This comes down to coding philosophy. Call it overkill, but I code on the side of caution.

[curaga]

Rich, yes, on success a function is allowed to alter errno, but to the best of my knowledge there are no values for errno for the functions used in aurora that do not indicated that some sort of a problem occurred.

Well, that's the deal: the standard allows a function to set errno to an error condition despite successing. One should only check errno if an error was returned, just like Rich said.

Consider for example a library function that can only set errno to EACCESS. It might be optimized to always set errno to EACCESS, and only report the status via its error code. This would be entirely "legal" by the standard.

[Rich]

Hi Blankman
Quoting once again from the manual:

Its value is significant only when the return value of the call indicated an error

Now, unless the documentation for one of the functions you are calling contradicts this, which some do, you are
checking the value of something which has no meaning and making a decision based on that test. What you are
doing in this case is not defensive programming, rather, checking to see that undefined behavior always
behaves the same way, from one system to the next, and ready to start coding exceptions when it doesn't.

[Blankman]

curaga, the standard allows errno to be set by a function on success, your assumption, that it's a error condition assumes facts not in evidence. Just because the variable is named errno may not mean it has to be an error, traditionally that's what it is but who knows, someday it could be an extended condition.

Oh and ah, if you're referring to EACCES, that is a bona fide error. If something returns that and an errno then a decision will have to be coded based on that that decides whether or not to continue. Which is basically what I've been saying all along, a decision on what to do would have to be coded.

Rich, yep, but that is today, but who knows about tomorrow, unless you can see the future. I've got bit a number of times by function call changes from one library version to the next. If I take steps to check things what's it to you? And you said I'm 'checking to see that undefined behavior always behaves the same way', not even close, since functions are allowed to alter errno I'm checking to see if a defined behavior has occurred. Once again for the functions in use that does not occur but I'll say again, that is today.

You guys want to stay in that box that's fine, if I choose to think outside that box that should be fine too.

[Blankman]

Oh yeah, I released version 1.8.3 of aurora to correct the issue Luca discovered, and yes, I'm still checking errno the same way as before.