aboutsummaryrefslogtreecommitdiff
path: root/src/mpack
Commit message (Collapse)AuthorAge
* fix(mpack): wrong encoding of integers beyond the int32 range #42085Suliman Abdulrazzaq2026-09-29
| | | | | | | | | | | | | | 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
* fix(style): some clang-tidy 22 fixesbfredl2026-05-11
| | | | | | | | | | | | | | | | | | | | | | CI currently uses clang-tidy 20, but this affects local builds and CI is going to be upgraded sooner or later. Some remaining systematic issues: - clang-tidy warns agains any atoi() or atol() usage (because of no error handling) - functions which takes (char *fmt, char *only_string_arg) and expect fmt to contain exactly one "%s" usage. - error: initializing non-local variable with non-const expression depending on uninitialized non-local variable (cppcoreguidelines-interfaces-global-init) This is a much worse problem in C++ (hence C++ core guidelines) where initialization is intermingled with arbitrary code execution. I "think" in plain C, the linker will either resolve all these deterministically or barf an error. But with some restructuring we could make all static initialization actually static..
* fix(mpack): boundary values for negative integer encoding #37255benarcher26912026-03-21
| | | | | | | | | | | | | | | | | | 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>
* fix(mpack): remove invalid bool definitionAndreas Schneider2025-01-27
| | | | | This causes build failures with gcc 15. Fixes #31723
* fix: buffer overrun in lmpack_session_receiveFred Sundvik2024-02-06
| | | | The offset was not taken into account when calculating the remaining buffer size.
* refactor: fix headers with IWYUdundargoc2023-11-28
|
* build: remove PVSdundargoc2023-11-12
| | | | | | | 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.
* build(deps): bump libmpack-lua to 1.0.11Christian Clason2023-10-09
| | | | | | update vendored libmpack-lua to match https://github.com/libmpack/libmpack-lua/releases/tag/1.0.11
* fix(build): distinguish vim.mpack from global require'mpack'bfredl2023-04-20
| | | | | problem: the api of vim.mpack is not compatible with a system provided mpack solution: don't require 'mpack' directly from the system path
* refactor(build): use vendored versions of mpack and luabitopbfredl2023-04-19
|
* fix(tests): fixes for using vim.mpack and more ASANbfredl2023-02-10
|
* fix(rpc): don't parse msgpack if buflen is 0 (#21899)zeertzjq2023-01-19
| | | | This prevents `buflen` from becoming a very large number when it is 0 when calling mpack_rtoken().
* fix(mpack): make sure a `bool` always is a `bool`bfredl2022-08-10
| | | | | | | | | | | before, RelWithDebInfo linking gave this warning: src/mpack/conv.h:36:16: warning: type of ‘mpack_unpack_boolean’ does not match original declaration [-Wlto-type-mismatch] 36 | MPACK_API bool mpack_unpack_boolean(mpack_token_t t) FUNUSED FPURE; | ^ src/mpack/conv.c:196:16: note: return value type mismatch 196 | MPACK_API bool mpack_unpack_boolean(mpack_token_t t) | ^
* refactor(api): use a unpacker based on libmpack instead of msgpack-cbfredl2022-06-02
| | | | | | | | | | 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!).
* refactor(PVS/V560): part of conditional expression is always true/falseDundar Göc2022-02-13
|
* chore: suppress -Wunused-but-set-variable warnsLewis Russell2021-12-19
|
* chore: fix typos (#16361)dundargoc2021-11-27
| | | | | | | | | | | | | | | | | | | | | | | | | | Co-authored-by: Brede Yabo Sherling Kristensen <bredeyabo@hotmail.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: István Donkó <istvan.donko@gmail.com> Co-authored-by: Julian Berman <Julian@GrayVines.com> Co-authored-by: bryant <bryant@users.noreply.github.com> Co-authored-by: Michael Lingelbach <m.j.lbach@gmail.com> Co-authored-by: nlueb <9465658+nlueb@users.noreply.github.com> Co-authored-by: Leonhard Saam <leonhard.saam@yahoo.com> Co-authored-by: Jesse Wertheim <jaawerth@gmail.com> Co-authored-by: dm1try <me@dmitry.it> Co-authored-by: Jakub Łuczyński <doubleloop@o2.pl> Co-authored-by: Louis Lebrault <louis.lebrault@gmail.com> Co-authored-by: Brede Yabo Sherling Kristensen <bredeyabo@hotmail.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: István Donkó <istvan.donko@gmail.com> Co-authored-by: Julian Berman <Julian@GrayVines.com> Co-authored-by: bryant <bryant@users.noreply.github.com> Co-authored-by: Michael Lingelbach <m.j.lbach@gmail.com> Co-authored-by: nlueb <9465658+nlueb@users.noreply.github.com> Co-authored-by: Leonhard Saam <leonhard.saam@yahoo.com> Co-authored-by: Jesse Wertheim <jaawerth@gmail.com> Co-authored-by: dm1try <me@dmitry.it> Co-authored-by: Jakub Łuczyński <doubleloop@o2.pl> Co-authored-by: Louis Lebrault <louis.lebrault@gmail.com>
* fix(vim.mpack): rename pack/unpack => encode/decode #16175Justin M. Keyes2021-10-30
| | | | | | | | | | | | | | | | | | | | | | | Problem: 1. "unpack" has an unrelated meaning in Lua: https://www.lua.org/manual/5.1/manual.html#pdf-unpack 2. We already have msgpackparse()/msgpackdump() and json_encode()/json_decode(), so introducing another name for the same thing is entropy. Solution: - Rename vim.mpack.pack/unpack => vim.mpack.encode/decode Caveat: This is incongruent with the `Unpacker` and `Packer` functions. - It's probably too invasive to rename those. - They also aren't part of our documented interface. - This commit is "reversible" in the sense that we can always revert it and add `vim.mpack.encode/decode` as _aliases_ to `vim.mpack.pack/unpack`, at any time in the future, if we want stricter fidelity with upstream libmpack. Meanwhile, `vim.mpack.encode/decode` is currently the total _documented_ interface of `vim.mpack`, so this change serves the purpose of consistent naming in the Nvim stdlib.
* fix(mpack): clang warning: unused variable #15968dundargoc2021-10-08
|
* fix(PVS/V1048): "variable was assigned the same value" #15870dundargoc2021-10-06
|
* ci(PVS): PVS/V009: add required header #15751dundargoc2021-09-21
|
* fix(ci): don't enrage the CI Gods by calling a file 'core.*'Björn Linse2021-09-09
|
* feat(lua): make vim.mpack support vim.NIL and vim.empty_dict()Björn Linse2021-09-09
|
* feat(lua): add vim.mpack for msgpack support in luaBjörn Linse2021-09-09
|
* fix(build): make vendored libmpack and libmpack-lua build properlyBjörn Linse2021-09-09
|
* build: vendor libmpack/libmpack-lua sources from ↵Björn Linse2021-09-09
| | | | b593809d93b5299bbee4e1d18e2e2d55f9fa53a6
* build: vendor libmpack source from libmpack/libmpack ↵Björn Linse2021-09-09
22b1fd90285117c995728511f9525d29520a8c82
generated by cgit (git 2.34.1) at 2026-10-20 00:44:24 +0000