If nothing else, unifying around sys/defs makes sense, although
currently -1 in sys/defs is mapped to SYS_ENOMEM and grepping for
SYS_EUNKNOWN didn't turn anything up.
I'd still like to work on the patch to get everything in line,
although I'd appreciate some guidance on what for a few cases.
> On Apr 10, 2017, at 7:42 AM, Sterling Hughes
> wrote:
>
> I don’t think we ever came to agreement, and things are a bit of a mishmash.
> Ben brings up a good point.
>
> Mynewt wide, in my view:
>
> * os_error is a relic, and sys/defs codes should be
On Mon, Apr 10, 2017 at 04:42:09PM +0200, Sterling Hughes wrote:
> I don’t think we ever came to agreement, and things are a bit of a
> mishmash. Ben brings up a good point.
>
> Mynewt wide, in my view:
>
> * os_error is a relic, and sys/defs codes should be used.
>
> * All functions should
Well, I replied quite differently, but I did not realize that os_error_t was a
relic. If that is the case, I agree with what you have here :-)
+1
> On Apr 10, 2017, at 7:42 AM, Sterling Hughes
> wrote:
>
> I don’t think we ever came to agreement, and things
I don’t think we ever came to agreement, and things are a bit of a
mishmash. Ben brings up a good point.
Mynewt wide, in my view:
* os_error is a relic, and sys/defs codes should be used.
* All functions should return “int” and not “os_error_t” or a
specific error type.
* 0 and -1 are
Not sure if anyone answered this. This is just my opinion of course:
* The OS functions should use return type os_error_t.
* Those functions should return OS_OK or some other OS error.
* Checks against functions with type os_error_t should be against OS_OK and not
0.
The bubbling up of errors,
While mucking about in the source I found a few places where the use of
OS_OK was either returned and checked against a hardcoded zero, or the
other way around, and some function signatures that give os_error_t or int
and return the other. The documentation has similar disconnects in portions
as