Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101986
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.44 as permitted sender)
To: Sara Golemon <pollita@php.net>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>,
 PHP internals <internals@lists.php.net>
References: <CAESVnVqAukZUar4xMk5Pr52u83m2RFq3iN=DRjJM18-izdqX=A@mail.gmail.com>
 <1e29d1b7-dbf4-35d5-61cc-8348c195984a@gmx.de>
 <1a373841-649b-aef0-1eea-637980463bbd@gmail.com>
 <CAESVnVoSMzoxhx440GwBs_ty=HD2DzZ+n6aQxkJn7PMO9z3sGw@mail.gmail.com>
Message-ID: <c4701c47-a77f-f5ee-0159-a53646219d25@gmail.com>
Date: Sun, 18 Mar 2018 15:55:39 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:59.0)
 Gecko/20100101 Thunderbird/59.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVoSMzoxhx440GwBs_ty=HD2DzZ+n6aQxkJn7PMO9z3sGw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Base Conversion Clowniness
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Technically, the internal API as it stands *can* return FAILURE
> already, though I can see your argument that a caller might assume
> that it'll never fail so long as they pass a string with a valid base.
> I don't think I agree with your point, as it's reasonable to expect an
> API caller to examine the return code of the function they're
> calling,. but I can see where you're coming from.

The problem is that if we return false, and the caller expects a number,
it may use the zval as numeric zval without conversion. I am not sure in
7.x using false as IS_LONG without conversion is safe anymore, but it is
possible that with proper initialization it would be. Other scenarios -
such as throwing without initializing the zval - may behave even worse.
Option C is relatively safe I think. Maybe B is safe too, and D can be
made safe with proper initialization - in any case that needs to be
checked.

> it's reasonable to expect an API caller to examine the return code of
the function they're
> calling

We aren't really good in documenting when API functions return
SUCCESS/FAILURE. In this particular case, the source indicates that if
you send it a string and the base is constant (common case), it would
never return FAILURE. So it's hard to blame extension writer who would
not check for FAILURE.
If we're changing the contract (or rather, having failed to document any
explicit contract, changing the implied contract defined by the source
code) we need at least to take some measures so that we don't create
subtle bugs in other extensions. Fortunately, in this case it seems to
be achievable.
-- 
Stas Malyshev
smalyshev@gmail.com