Re: Removing os_error_t

+1 for this idea. I like the idea of a package that holds error codes. Regarding error codes type, I don¹t have a strong opinion. My preference would be enums because my IDE can help me and the compiler can help a bit. Paul On 9/11/16, 10:44 AM, "Sterling Hughes" wrote:

Re: Removing os_error_t

Fine with me, but I also do like using BOOLEAN types as well and have functions return either TRUE or FALSE. I think it makes the code easier to read… so I hope we can still use TRUE or FALSE for some functions. > On Sep 11, 2016, at 11:32 AM, Christopher Collins wrote: >

Re: Removing os_error_t

On Sun, Sep 11, 2016 at 10:42:07AM -0700, Sterling Hughes wrote: [...] > 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

Removing os_error_t

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