Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105779
MIME-Version: 1.0
References: <4bdc84d133912367ab9d5139f37f9a6e@exussum.co.uk>
In-Reply-To: <4bdc84d133912367ab9d5139f37f9a6e@exussum.co.uk>
Date: Thu, 23 May 2019 14:36:21 +0200
Message-ID: <CAF+90c8Do2PbK9=Yfcbr4gzpAx7uYcp-eNaJjw+mXmyrWzJz8Q@mail.gmail.com>
To: Scott Dutton <scott@exussum.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000049d4ab05898d55f0"
Subject: Re: [PHP-DEV] [RFC] Base convert changes
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000049d4ab05898d55f0
Content-Type: text/plain; charset="UTF-8"

On Sat, May 18, 2019 at 11:22 AM Scott Dutton <scott@exussum.co.uk> wrote:

> Hi all
>
> I have made some changes to base_convert which I feel would be more
> consistent with the current PHP (warning when there are errors, and not
> just returning the best value it can)
>
> The RFC has some examples of what will change.
>
> Currently the code works but a lot of tests fail due to extreme range's
> (also mentioned in the RFC)
>
> If this passes I will fix the effected tests and add some more covering
> the new behavior.
>
> https://wiki.php.net/rfc/base_convert_improvements
>
> Let me know your thoughts
>
> Thanks
>
> Scott
>

Hi Scott,

I definitely agree with the part of the RFC that warns on garbage
characters in the string. I'm not so sure about the changes in sign
handling. The problem I see is that certain bases (in particular hex) are
pretty much never used with an explicit sign, instead they are understood
to be in two's complement representation.

For example, code like this will currently work:

var_dump(dechex(0xffffffff00000000));
// string(16) "ffffffff00000000"

While after your change it will result in "-100000000", which for hex
numbers is rather unexpected. (This example is somewhat non-great because
there is a loss of accuracy for 64bit numbers represented as doubles -- the
same examples with 32-bit integers on 32-bit systems would be fully
reliable.)

Nikita

--00000000000049d4ab05898d55f0--