You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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;
The text was updated successfully, but these errors were encountered:
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.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
:The text was updated successfully, but these errors were encountered: