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 <[email protected]> wrote: > > 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 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. > > I agree with removing enum return codes, as enums have odd semantics and > don't provide any real benefit in my opinion [*]. 0 for success, > positive for data, negative for error sounds like a fine convention to > me. > > Chris > > [*] The type of an enum is implementation defined (4). The type of an enum > value is always int (3): > > (ISO/IEC 9899:201x, 6.7.2.2) > 3 The identifiers in an enumerator list are declared as constants that > have type int and may appear wherever such are permitted. An enumerator > with = defines its enumeration constant as the value of the constant > expression. If the first enumerator has no =, the value of its > enumeration constant is 0. Each subsequent enumerator with no = defines > its enumeration constant as the value of the constant expression > obtained by adding 1 to the value of the previous enumeration constant. > (The use of enumerators with = may produce enumeration constants with > values that duplicate other values in the same enumeration.) The > enumerators of an enumeration are also known as its members. > > 4 Each enumerated type shall be compatible with char, a signed integer > type, or an unsigned integer type. The choice of type is > implementation-defined, but shall be capable of representing the > values of all the members of the enumeration.The enumerated type is > incomplete until immediately after the } that terminates the list of > enumerator declarations, and complete thereafter.
