| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
vim.mpack.encode() picks the msgpack size of a negative integer from its
low 32 bits only, so -(2^32 + 5) is written as a negative fixint and
decodes as -5. Numbers beyond +-2^53 trip an assertion in debug builds.
In release builds, numbers below -2^63 or from 2^64 up go through
out-of-range conversions: -1.5 * 2^63 decodes as 2^62.
Solution:
Use int64 whenever the high word is not a sign extension. Encode numbers
outside [-2^63, 2^64), including NaN and infinities, as floats.
AI-assisted
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
libmpack encodes boundary values -129 and -32769 with wrong integer
sizes:
- -129 as int8 instead of int16
- -32769 as int16 instead of int32
because the boundary checks compare against the wrong values (e.g., lo
< 0xffffff7f instead of lo < 0xffffff80). This caused data corruption:
-129 would decode as 127.
Solution:
Fix off-by-one errors in the two's complement boundary constants:
0xffffff80 (-128, min int8) and 0xffff8000 (-32768, min int16).
Fixes #37202
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
|
| |
|
|
|
|
|
| |
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
|
| | |
|
| | |
|
|
|
22b1fd90285117c995728511f9525d29520a8c82
|
