Improve performance of intval('+0b...', 2) and intval('0b...', 2)

[ndossche]

For this benchmark:

<?php

for ($i = 0; $i < 10000000; $i++) {
    intval('+0b11111111111100000000', 2);
}

On an i7-4790:

Benchmark 1: ./sapi/cli/php x.php
  Time (mean ± σ):     527.3 ms ±   8.1 ms    [User: 523.5 ms, System: 2.4 ms]
  Range (min … max):   515.4 ms … 545.1 ms    10 runs

Benchmark 2: ./sapi/cli/php_old x.php
  Time (mean ± σ):     629.3 ms ±   6.0 ms    [User: 625.9 ms, System: 1.8 ms]
  Range (min … max):   622.8 ms … 643.2 ms    10 runs

Summary
  ./sapi/cli/php x.php ran
    1.19 ± 0.02 times faster than ./sapi/cli/php_old x.php

On an i7-1185G7:

Benchmark 1: ./sapi/cli/php x.php
  Time (mean ± σ):     429.6 ms ±   7.2 ms    [User: 427.5 ms, System: 1.6 ms]
  Range (min … max):   423.0 ms … 449.0 ms    10 runs
 
Benchmark 2: ./sapi/cli/php_old x.php
  Time (mean ± σ):     486.0 ms ±  10.7 ms    [User: 479.2 ms, System: 2.3 ms]
  Range (min … max):   476.4 ms … 507.3 ms    10 runs
 
Summary
  ./sapi/cli/php x.php ran
    1.13 ± 0.03 times faster than ./sapi/cli/php_old x.php

[Girgias]

This looks correct to me, but I think this has reminded me that intval() doesn't support the recent octal prefix addition, so 0o14 would be returned as 0 rather than 12.

Which is somehow missed when working on the RFC as some other related functions already supported the syntax :/

[ndossche]

This looks correct to me, but I think this has reminded me that intval() doesn't support the recent octal prefix addition, so 0o14 would be returned as 0 rather than 12.

Yeah you're correct