Repository navigation
C++: Non-canonical lists lowering reuses the C++ result vector #1592
Description
This can be seen in the tests/runtime/lists example, in function wasi_http_headers_roundtrip.
Here the C++ result vector storage is also used to lower the elements. These types may or may not have the same size and might disagree on layout. For sure in-depth copying and overwriting the elements in place is not a good idea. The lowered result should be allocated before the copy and the lifted result array freed after the copy. I only found this because my compiler had a different idea of the C++ type layout.
This error is subtle and doesn't show up in the test.
Activity
cpetig commentedon Apr 16, 2026
It looks like the only noticeable difference is due to
g++storingtuples' elements in reverse order, while clang++ uses normal order.cpetig commentedon Apr 16, 2026
Update: https://stackoverflow.com/questions/9641699/why-is-it-not-good-to-use-recursive-inheritance-for-stdtuple-implementations/9643480#9643480 is probably the best explanation of the situation.
<rant>Another C++ type which gives zero guarantees about the binary representation and thus is incompatible between compiler variants and thus unsuitable for FFI.cpetig commentedon May 30, 2026
See https://github.com/cpetig/wit-bindgen/tree/vector_alloc for in progress attempts at this issue.
But I really get the impression that in codegen I should have been more explicit at distinguishing canonical ABI representation types (with owned and borrowed flavor changing the dtor behavior) and C++ convenience standard types in arguments and results. Typically at some depth the convenience type (e.g. std::span) starts to contain canonical types (wit::vector). I guess this also means that I need to generate two variants for each WIT record type, owned and borrowed, which are binary compatible but behave different on destruction.
This distinction of course only makes most sense as long as you want to avoid in depth copying of data types.
Any insights from your perspective on this, @TartanLlama ?
rajsite commentedon Jun 12, 2026
Been experimenting with porting a CPP library (with a lot of llm assistance) and think I hit this issue in wit-bindgen v0.57.1. Had a decent pre-existing test suite to leverage and it came up with a patch to the generated CPP. I captured it in an example repo in-case it's helpful (has the example wit and helper scripts): https://github.com/rajsite/wit-bindgen-issue-1592
Can see the commentary it came up with in the patch script and a commit showing the patch applied to the generated CPP.
Edit: The llm also came up with an update to the vector_alloc branch (see github compare) that it says passes in wit-bindgen and tested against my project.
cpetig commentedon Jul 2, 2026
Sorry to see you running into this. This is an open design gap which dates back to way before the original merge, but all the tests showed that it was suitable enough to be merged. See #1283 (comment) and #1283 (comment)