If only it were so simple. read and write, for example, return a number less than zero on error and a non-negative number on success, and malloc returns zero on error, and nonzero on success.
The general rule for early C seems to be “whatever’s the best way to cram a return value or an error in an int” (probably the correct decision for the time)
Also, these new functions return a bool, which, in C23, gets integer-converted to zero for false and one for true (https://en.cppreference.com/w/c/language/bool_constant. C17 had macros for true and false, with false being zero)
and the reverse, converting to bool similarly has zero fro false (https://en.cppreference.com/w/c/language/conversion#Boolean_...):
“A value of any scalar type (including nullptr_t) (since C23) can be implicitly converted to _Bool. The values that compare equal to an integer constant expression of value zero are converted to 0 (false), all other values are converted to 1 (true).”
Functions that only return an error code like `stat`, `connect`, and the proposed ckd_add, return 0 on success and nonzero on error.
Here, the committee just standardized existing practice, namely the gcc builtins. We just adjusted the call sequence in putting the pointer parameter for the result first.
if(ckd_add(&result_add, a, b) == CKD_SUCCESS) { ... }
if(CKD_SUCCESS(ckd_add(&result_add, a, b))) { ... } int rc = func();
if( rc ) { /*handle error*/ }
They felt fine changing the argument order, why stick with the reverse polarity?
They also give example code
I can see that fits with “most of the time, anything positive means ‘no error’”, for example in malloc, write, read or printf, but these new functions return bool, not int, and the chosen method will require writing a double negation sometimes: That’s not too bad, but if I were to see I would expect that to test for failure, not success.Because of that, I think I would have chosen to return true on success, false on failure. I’m curious as to what arguments led to the choice made.