Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101985
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.176 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <1a373841-649b-aef0-1eea-637980463bbd@gmail.com>
References: <CAESVnVqAukZUar4xMk5Pr52u83m2RFq3iN=DRjJM18-izdqX=A@mail.gmail.com>
 <1e29d1b7-dbf4-35d5-61cc-8348c195984a@gmx.de> <1a373841-649b-aef0-1eea-637980463bbd@gmail.com>
Date: Sun, 18 Mar 2018 18:41:59 -0400
Message-ID: <CAESVnVoSMzoxhx440GwBs_ty=HD2DzZ+n6aQxkJn7PMO9z3sGw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: [RFC] Base Conversion Clowniness
From: pollita@php.net (Sara Golemon)

On Sun, Mar 18, 2018 at 5:49 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>>> https://wiki.php.net/rfc/base-convert
>>
>> Is there any chance to revive this RFC?  There are at least three
>> tickets in the bug tracker regarding the sloppy behavior of base_convert():
>
> I think if we want to take this RFC forward it should be reduced to
> either proposing one action, instead of four, or at the worst case,
> choice of two for vote.
>
Agreed, I presented it as more options initially so that we could talk
out what options might be preferred before going to any kind of
voting.

Given the lack of opinion on the matter, I'd probably be inclined to
present option B as the official proposal.  Consistent with PHP
functional APIs.

> It also needs BC impact section added - AFAIK it may break some tests
> and _php_math_basetozval is PHPAPI, which means besides 4 uses in core,
> any extension could be using it and that extension may not be prepared
> for it working differently. Which means if we change it, the failure
> behavior that happens should be such that application ignoring it would
> not have trouble - at least not worse than today.
>
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.

-Sara