title: json_decode and PHP: JSON_BIGINT_AS_STRING disparity
body: <p>Using <a href="http://www.sitepoint.com/quick-tip-get-homestead-vagrant-vm-running/" rel="nofollow">Homestead</a>, I try to run the BIGINT example #5 from <a href="http://php.net/manual/en/function.json-decode.php" rel="nofollow">the PHP docs</a> and I get an "Integer overflow notice". The flag <code>JSON_BIGINT_AS_STRING</code> is ignored, and the result is invalid (a maximum bigint of 9223372036854775807).</p>
  
  <p>The Homestead instance has the following software stack:</p>
  
  <ul>
  <li>PHP 5.6.9</li>
  <li>JSON 1.3.6 with JSON-C headers and lib 0.11.99.</li>
  </ul>
  
  <p>I then tested it on 3v4l, and <a href="http://3v4l.org/slSnr" rel="nofollow">it works</a>. I don't know their JSON setup.</p>
  
  <p>I then tested it on OS X's pre-installed PHP which is:</p>
  
  <ul>
  <li>PHP 5.5 </li>
  <li>JSON 1.2.1 and no JSON-C headers/lib. </li>
  </ul>
  
  <p>This works, too - just like in the docs.</p>
  
  <p>Subsequently, I found <a href="https://github.com/remicollet/pecl-json-c/issues/6" rel="nofollow">this issue</a> which leads to <a href="https://github.com/remicollet/pecl-json-c/commit/5822493892c65219db07378f22bb3b1ccb5fdd06" rel="nofollow">this commit</a> 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.</p>
  
  <p>Are there any good solutions for this that don't require internal alteration of libraries used, like Guzzle?</p>
  
  <p>Edit: Upon searching further, I have found <a href="http://tldrify.com/9d0" rel="nofollow">this</a> which confirms that <em>one developer's opinion</em> is the cause of problems here.</p>