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.
