`wirefilter_get_last_error()` (`ffi/src/lib.rs:223-225`) is the only string-returning FFI entry point
that hands back a borrowed `*const c_char`, pointing into a thread-local `CString`'s backing
`Vec` (`ffi/src/cstring.rs:43-49`). Every other heap-allocated string this API returns comes back
as an owned `RustAllocatedString`, freed via `wirefilter_free_string`.
Neither the doc comment (`lib.rs:221`) nor the generated header states a lifetime for the returned
pointer. The backing buffer can reallocate: `write_last_error!` (used at every error site) clears and
re-appends the message (`cstring.rs:21-33`), which grows the buffer if the new message is longer than
whatever capacity the previous one left — so the pointer's actual validity is "until the next
`wirefilter_*` call on this thread," an implicit contract that isn't written down anywhere a caller
can find it.
Is that the intended contract? If so, could it be stated explicitly in the doc comment and header —
or would it be worth returning an owned string here instead, for consistency with the rest of the FFI
surface?
Found with the rust-in-peace pipeline.
`wirefilter_get_last_error()` (`ffi/src/lib.rs:223-225`) is the only string-returning FFI entry point
that hands back a borrowed `*const c_char`, pointing into a thread-local `CString`'s backing
`Vec` (`ffi/src/cstring.rs:43-49`). Every other heap-allocated string this API returns comes back
as an owned `RustAllocatedString`, freed via `wirefilter_free_string`.
Neither the doc comment (`lib.rs:221`) nor the generated header states a lifetime for the returned
pointer. The backing buffer can reallocate: `write_last_error!` (used at every error site) clears and
re-appends the message (`cstring.rs:21-33`), which grows the buffer if the new message is longer than
whatever capacity the previous one left — so the pointer's actual validity is "until the next
`wirefilter_*` call on this thread," an implicit contract that isn't written down anywhere a caller
can find it.
Is that the intended contract? If so, could it be stated explicitly in the doc comment and header —
or would it be worth returning an owned string here instead, for consistency with the rest of the FFI
surface?
Found with the rust-in-peace pipeline.