On Mon, 24 Mar 2025 10:18:50 +0000 Douglas Raillard <[email protected]> wrote:
> > https://lore.kernel.org/all/b6bdb34e70d970e8026daa3503db6b8e5cdad524.1601848695.git.zanu...@kernel.org/T/#u > > > > So, I think it should always print the STR_VAR_LEN_MAX value. > > That makes sense. It's tempting to keep the actual length value though as > native Rust strings are not null-terminated, so > it could make it nicer to emit events from Rust code. From a cursory look, > the in-tree Rust code seems to be using both > &str and &CStr (the latter being null-terminated for FFI needs) so I'm not > sure what's the plan around those > and what's the established convention if any. > > > Steve, can you check it? So I did take this patch, but thinking about this more, I may remove it. The __get_str() doesn't expect a string end. The parser should limit it, as the length of the string is saved in the ring buffer. Just like other trace events where dynamically size strings only use "%s" and __get_str(). I think the real fix is to replace the "%.*s" with "%s". -- Steve
