Removing os_error_t

[Sterling Hughes]

Hey,

Across the OS, we have two interfaces: some that use os_error_t, and the 
other that uses int’s for return codes.

Personally, I have never liked using a typedef for an error code 
(largely as a short hand for an enum.)  I like to have a single variable 
“rc” that I use for error accounting — which works fine with 
enums, but if the type changes under me, then all the code doesn’t 
compile.  Plus, there are cases where I want to return values and error 
codes in a single int (positive = val, negative = error code.)  In order 
to stick with the spirit of an enum, I’d have to separate the value 
and return code, and I’m lazy and dislike functions with unnecessarily 
long signatures.

And “os_error_t” only applies to OS error codes, and our libraries 
are mixed.  FS uses ‘#defines’, whereas BLE uses enums again.

So — prior to 1.0, I think we should clean this up.  My proposal is to 
go with plain old integers as error codes across the system.  0 is no 
error, a negative value is the error code and a positive value can be 
used when returning actual data (and must be marked in the function 
signature/doxygen comment.)  Although, if we want to go the enum route, 
I’m happy with that too, but I think we should clean up the code that 
currently uses integers as return values (there is a lot of it), to move 
to cleanly specifying where the error parameters are.

Sterling