On Sun, Feb 19, 2023, at 08:31, Max Kellermann wrote:
> Hi,
>
> I've done a bit of refactoring work around code using "zend_result",
> but I keep wondering why it even exists.
>
> It was added in 1999 by commit 573b46022c46 in a huge 16k line commit
> (as macros, converted to enum in 2012 by commit e3ef84c59bf).
>
> In 1999, C99 was brand new, and the "bool" type had just been
> introduced to the C language - yes, C was 18 years old when a native
> boolean type was added - but PHP didn't switch to C99 for another 19
> years later (b51a99ae358b).
>
> C had a long history of abusing "int" as boolean type, wasting 2 or 4
> bytes for something that could have easily fit in 1 byte. As if that
> wasn't obscure enough, POSIX used 0 for success and -1 for error (and
> missed the chance to return error codes, and instead added a global
> variable for that which caused more headaches). (And don't get me
> started on the horrible strcmp() return value.) Returning errors in C
> is a huge obscure and inconsistent mess; every function does it
> differently.
>
> This is PHP's original definition:
>
> #define SUCCESS 0
> #define FAILURE -1 /* this MUST stay a negative number, or it may effect
> functions! */
>
> This appears to follow the POSIX school of bad error return values.
> There's a comment which makes the thing even more obscure.
>
> Really, why does it need to be negative?
>
> Why does it imitate POSIX instead of using a boolean? (i.e. "int" and
> non-zero for success for old-schoolers)
>
> The obvious way to indicate success or failure (without giving details
> about the nature of the failure) would be to just return "bool". With
> C99, any discussion on "0 or 1" vs "-1 or 0" is obsolete - there is
> now a canonical boolean type that should be used.
>
> Of course, I know already that getting rid of "zend_result" in favor
> of "bool" would be a major API breakage that requires careful
> refactoring of almost all extensions.
>
> I just want to understand why "zend_result" was ever invented and why
> it uses those surprising integer values. The commit message and that
> code comment doesn't explain it.
>
> Rephrased: do you consider it a worthy goal to eventually get rid of
> "zend_result", or do you believe it's good API design that should stay
> forever?
>
> (Yet again I wish PHP was fully C++ - unlike C, C++ has strongly-typed
> enums which cannot be casted implicitly to "int" or "bool"; that makes
> refactoring a lot easier and safer.)
>
> Max
Any type that has only two values is isomorphic to a boolean. However, for us
humans, not all two-valued types are semantically equivalent.
If you have a function like zend_hash_exists(), true and false are directly
meaningful values.
If you have a function like zend_stream_open_function(), SUCCESS and FAILURE
are directly meaningful values.
Now, if you make zend_stream_open_function() return a boolean instead, it's no
longer clear what the return value means. Does a true return value mean that
the stream was opened successfully, or that it failed?
For a PHP programmer, that might sound silly -- of course true means success.
However, in C the common error reporting convention is actually the other way
around: Non-zero return values indicate failure. This means that false
indicates success and true indicates failure. (I'm not kidding you -- I'm
literally working on a project that uses boolean return values with this
convention right now.)
The current guideline for use of bool and zend_result in php-src is that bool
is an appropriate return value for "is" or "has" style functions, which return
a yes/no answer. zend_result is an appropriate return value for functions that
perform some operation that may succeed or fail.
I think that's a pretty reasonable state of things, and don't think there is a
need to change it.
Regards,
Nikita
