json_decode and PHP: JSON_BIGINT_AS_STRING disparity

Question

Using Homestead, I try to run the BIGINT example #5 from the PHP docs and I get an "Integer overflow notice". The flag JSON_BIGINT_AS_STRING is ignored, and the result is invalid (a maximum bigint of 9223372036854775807).

The Homestead instance has the following software stack:

PHP 5.6.9
JSON 1.3.6 with JSON-C headers and lib 0.11.99.

I then tested it on 3v4l, and it works. I don't know their JSON setup.

I then tested it on OS X's pre-installed PHP which is:

PHP 5.5
JSON 1.2.1 and no JSON-C headers/lib.

This works, too - just like in the docs.

Subsequently, I found this issue which leads to this commit and seems to be what's causing the problems here, but why does Remi invalidate >64bit numbers and call integer overflow, despite the default JSON extension (present on 3v4l and OS X natively) not doing that? Doesn't this violate the claim that it's a "drop in replacement"? In its current state, this extension, which is included by default in many installations, goes directly against PHP's official documentation.

Are there any good solutions for this that don't require internal alteration of libraries used, like Guzzle?

Edit: Upon searching further, I have found this which confirms that one developer's opinion is the cause of problems here.

bwoebi · Accepted Answer · 2015-06-28 01:32:52Z

2

+50

Yes, it's really just Remis opinion here. That way it clearly is not a 100% drop-in replacement. You ask why it's allowed? Because nobody can disallow a free developer to write his own code the way he wants.

So… all you can do is complaining and compiling ext/json yourself (instead of using JSON-C).

That means cloning from php-src source (https://github.com/php/php-src), checkout PHP-5.6 branch, navigate into ext/json directory and compile via phpize && ./configure && make install. Then add that extension to your php.ini instead of the json-c extension. [If necessary, you may need to first install some compiling tools...]

Note that with PHP 7.0 the json extension is replaced by a new implementation (see also the RFC: https://wiki.php.net/rfc/jsond), which doesn't have these issues and additionally has no license problems.

answered Jun 28, 2015 at 1:32

bwoebi

23.8k5 gold badges64 silver badges81 bronze badges

Sign up to request clarification or add additional context in comments.

9 Comments

Swader Over a year ago

Can jsond not be backported into 5.6 and lower to make for an actually working extension?

bwoebi Over a year ago

@Swader It could, but there are many changes in ZE 3, it wouldn't be worth it. Just take current php-src json ext and compile it ;-)

Swader Over a year ago

That's fine for me, but what about the users of my library whose implementations will now break because many distros package a broken (and not officially documented) jsonc implementation by default?

bwoebi Over a year ago

I'm sorry, but there's nothing you can do about except warning, giving instructions etc.. All you can do about that is basically writing your own parser in userland.

Swader Over a year ago

Ok, thanks. Bit disappointed that one developer can do so much damage and so few people care about it (I even submitted a bug for the official docs, to warn people but it was promptly closed).

|

Collectives™ on Stack Overflow

json_decode and PHP: JSON_BIGINT_AS_STRING disparity

1 Answer 1

9 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

9 Comments

Your Answer

Sign up or log in

Post as a guest

Related