Seems related to issue https://github.com/msgpack/msgpack-php/issues/119, but occurs in serialization. Extension built from master branch just an hour before, but confirmed with 2.2.0RC1 and 2.1.2 PECL builds as well - all affected.
msgpack_pack is producing incorrectly 0xD2 (signed int32) type specifier, so it is not an unpacker issue.
It seems it is caused by long being 4 byte, while zend_long is correctly 8 byte in size. Therefore, msgpack_pack_long accepting long argument is truncating zend_long value, then invokes msgpack_pack_real_int32 treating it as signed 32-bit value. The correct behavior is observed after replacing msgpack_pack_long by msgpack_pack_long_long in msgpack_serialize_zval:
case IS_LONG:
msgpack_pack_long_long(buf, zval_get_long(val_noref));
break;
Seems related to issue https://github.com/msgpack/msgpack-php/issues/119, but occurs in serialization. Extension built from
master
branch just an hour before, but confirmed with 2.2.0RC1 and 2.1.2 PECL builds as well - all affected.On linux builds:
On windows builds (VS17 x64 TS):
msgpack_pack
is producing incorrectly0xD2
(signed int32) type specifier, so it is not an unpacker issue.It seems it is caused by
long
being 4 byte, whilezend_long
is correctly 8 byte in size. Therefore,msgpack_pack_long
acceptinglong
argument is truncatingzend_long
value, then invokesmsgpack_pack_real_int32
treating it as signed 32-bit value. The correct behavior is observed after replacingmsgpack_pack_long
bymsgpack_pack_long_long
inmsgpack_serialize_zval
: