Ошибка оракула
В одном из проектов при исправлении ошибки всплыло неожиданное. Кусок кода, который работал ошибочно, родился
Всё работало хорошо, пока ПХП был
Беда в том, что драйвер (в этом месте), похоже, остался в пределах 32 бит, код:
$var = null;
$st = oci_parse($con, "SELECT :int FROM DUAL");
oci_bind_by_name($st, 'int', $var, -1, SQLT_INT);
foreach ([100500, PHP_INT_MAX, 2147483648] as $var) {
oci_execute($st);
echo oci_fetch_array($st, OCI_NUM)[0], "\n";
}Выведет: 100500, -1, -2147483648. Решение я пока знаю только одно: не использовать для целых, которые не помещаются в 32 бита указание типа SQLT_INT.
Проблема в файле oci8_statement.c (это текущий код драйвера из PHP 5.7):
switch (bind->array.type) {
case SQLT_NUM:
case SQLT_INT:
case SQLT_LNG:
...
ZVAL_LONG(entry, ((ub4 *)(bind->array.elements))[i]);
...Значение в этом месте приводится к четырёхбайтному целому.
PHP7: строки с Unicode-вхождениями

ПХП тут сделал маленький шаг к унификации синтаксиса с Руби, Джаваскриптом и HHVM — ввёл возможность указывать Юникодные символы через последовательность на скриншоте. Сегодня я выписал текущую версию из репозитория (она, кстати, не компилируется без исправлений в коде) и убедился, что всё работает.
Скорость PHP7 на интерпретаторе Brainfuck

У меня есть старинная забава — брать свой оптимизирующий интерпретатор языка «Брейнфак» и запускать программу, вычисляющую число «Пи» под разными версиями ПХП, чтобы посмотреть их производительность. Тест довольно синтетический, но посмотреть всё равно интересно.
Сравнил в данном случае версии 5.5.14 и сегодняшнюю сборку 7.0, разница всё равно заметна, хоть и не так впечатляюща, как в случае с «Вордпрессом» — там разница в два раза.
Время у меня на скриншоте общее — то есть трансляция программы на «Брейнфаке» в ПХП и запуск получившегося через eval.