| 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.
|
| |
|
|
| |
This prevents `buflen` from becoming a very large number when it is 0
when calling mpack_rtoken().
|
| |
|
|
|
|
|
|
|
|
| |
Currently this is more or less a straight off reimplementation,
but this allow further optimizations down the line, especially
for avoiding memory allocations of rpc objects.
Current score for "make functionaltest; make oldtest" on a -DEXITFREE build:
is 117 055 352 xfree(ptr != NULL) calls (that's NUMBERWANG!).
|
| | |
|
| |
|
