summaryrefslogtreecommitdiffstatshomepage
path: root/src/mpack
AgeCommit message (Collapse)AuthorFiles
2026-03-21fix(mpack): boundary values for negative integer encoding #37255benarcher26912
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>
2025-01-27fix(mpack): remove invalid bool definitionAndreas Schneider1
This causes build failures with gcc 15. Fixes #31723
2024-02-06fix: buffer overrun in lmpack_session_receiveFred Sundvik1
The offset was not taken into account when calculating the remaining buffer size.
2023-11-28refactor: fix headers with IWYUdundargoc1
2023-11-12build: remove PVSdundargoc5
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.
2023-10-09build(deps): bump libmpack-lua to 1.0.11Christian Clason1
update vendored libmpack-lua to match https://github.com/libmpack/libmpack-lua/releases/tag/1.0.11
2023-04-20fix(build): distinguish vim.mpack from global require'mpack'bfredl2
problem: the api of vim.mpack is not compatible with a system provided mpack solution: don't require 'mpack' directly from the system path
2023-04-19refactor(build): use vendored versions of mpack and luabitopbfredl2
2023-02-10fix(tests): fixes for using vim.mpack and more ASANbfredl2
2023-01-19fix(rpc): don't parse msgpack if buflen is 0 (#21899)zeertzjq1
This prevents `buflen` from becoming a very large number when it is 0 when calling mpack_rtoken().
2022-08-10fix(mpack): make sure a `bool` always is a `bool`bfredl1
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) | ^
2022-06-02refactor(api): use a unpacker based on libmpack instead of msgpack-cbfredl2
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!).
2022-02-13refactor(PVS/V560): part of conditional expression is always true/falseDundar Göc1
2021-12-19chore: suppress -Wunused-but-set-variable warnsLewis Russell1
2021-11-27chore: fix typos (#16361)dundargoc1
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>
2021-10-30fix(vim.mpack): rename pack/unpack => encode/decode #16175Justin M. Keyes1
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.
2021-10-08fix(mpack): clang warning: unused variable #15968dundargoc1
2021-10-06fix(PVS/V1048): "variable was assigned the same value" #15870dundargoc2
2021-09-21ci(PVS): PVS/V009: add required header #15751dundargoc5
2021-09-09fix(ci): don't enrage the CI Gods by calling a file 'core.*'Björn Linse5
2021-09-09feat(lua): make vim.mpack support vim.NIL and vim.empty_dict()Björn Linse1
2021-09-09feat(lua): add vim.mpack for msgpack support in luaBjörn Linse1
2021-09-09fix(build): make vendored libmpack and libmpack-lua build properlyBjörn Linse2
2021-09-09build: vendor libmpack/libmpack-lua sources from ↵Björn Linse1
b593809d93b5299bbee4e1d18e2e2d55f9fa53a6
2021-09-09build: vendor libmpack source from libmpack/libmpack ↵Björn Linse9
22b1fd90285117c995728511f9525d29520a8c82
Copyright © 2025 - 2026 Wayne Cole. WTFPL. Attribution appreciated. No warranty. Not liable for bodily damages.