Seems related to issue #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.
$payload = 3119646122;
$pack = msgpack_pack($payload);
print bin2hex($pack[0]) . "\r\n";
$unpack = msgpack_unpack($pack);
var_dump($unpack);
On linux builds:
On windows builds (VS17 x64 TS):
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 #119, but occurs in serialization. Extension built from
masterbranch 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_packis producing incorrectly0xD2(signed int32) type specifier, so it is not an unpacker issue.It seems it is caused by
longbeing 4 byte, whilezend_longis correctly 8 byte in size. Therefore,msgpack_pack_longacceptinglongargument is truncatingzend_longvalue, then invokesmsgpack_pack_real_int32treating it as signed 32-bit value. The correct behavior is observed after replacingmsgpack_pack_longbymsgpack_pack_long_longinmsgpack_serialize_zval: