[RFC] Base Conversion Clowniness View as Markdown

Hi!

I think it depends which release. If next 5.x, then I think a warning
might be acceptable.

I was talking about existing stable branches (5.4 and 5.5) of course.
5.6 still can be discussable.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Just a little note - I don't think any option that adds warnings where
there were not warnings is acceptable in this case for any stable
version. There are dozens of ways extra warning could break an existing
app.

I can see the argument for that, though anything depending on buggy
conversion is probably broken.

Also, wouldn't simple regexp or filter or is_numeric check solve this
issue while allowing much more flexible reaction to wrong data? I'm not
sure that more warnings is better than more data checking.

Sure, one could validate before conversion with something like:

if (strcmp($val, base_convert($val, $base, $base))) {
/* $val isn't purely in base $base */
} else {
$newval = base_convert($val, $base, $newbase);
}

And a proper app should have logic like that regardless.

However I do think that when apps don't apply such forward-thinking
logic, we should be prepared to be noisy about it (as we do with an
fopen() call which wasn't preceeded by an is_readable()/is_writable()
check)

-Sara

You can only reasonably prepare for that if you are aware of how the
implementation works, so that's about 30 of us ... before yesterday was
probably less than 10 ...

I'm with you, it's crap, fix it ...

Cheers
Joe

https://wiki.php.net/rfc/base-convert

Is there any chance to revive this RFC? […]

Huh... It's got my name on it, but I can't for the life of me recall
starting this up.

I agree with past-me, however. This is some clowny behavior.

Let's consider the conversation reopened. […]

That's the spirit! Thanks.

I tend to prefer option C (throw a Warning, stop processing, and return
the value up to that point). Option B (throw a Warning and return FALSE
on unexpected characters) might be cleaner, but we're not that picky
elsewhere, and the return value might not even be checked, and thus
easily misinterpreted as zero.

--
Christoph M. Becker

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