babeltrace | sink.ctf.fs escaping of struct member names

[Philippe Proulx]

On Thu, Dec 4, 2025 at 5:10 AM MOESSBAUER, Felix via lttng-dev
<lttng-dev at lists.lttng.org> wrote:
>
> In my opinion, the escaping of the struct member names in the CTF
> writer is not correct according to the CTF 1.8.3 spec: Section 4.2.1
> states, that reserved keywords must not be used and the recommended
> escaping is a underscore prefix. However, the spec does not state any
> other names that need to be escaped and by that also not names starting
> with an underscore itself.
>
> IOW: The CTF writer currently unconditionally escapes all struct member
> names, which I assume to be incorrect

It's not incorrect per se.

Underscore as a member name escaping mechanism has always been a
nightmare in CTF 1.8. For example, given:

    uint8 _len;
    string _strings[length here];

Should we use `_len` or `len`? And what about this:

    struct {
        uint8 meow;
        uint8 _meow;
    } _mix;

LTTng chooses to escape everything with `_`, except the packet header,
packet context, and event record header names it knows. We did exactly
the same in `sink.ctf.fs`.

CTF 1.8 doesn't specify `cpu_id` by the way; it's an LTTngism.

CTF 2 solves all of that!

Since CTF 1.8 is pretty much deprecated at this point, I want to invest
as little time as possible in anything related to this legacy format,
whatever the project. Just make it work considering the known use cases.

Therefore, for your specific problem, I suggest that you specifically
avoid the "protection" (escaping) for `cpu_id` in the packet context
field class _only for LTTng traces_. It should be good enough and make
Trace Compass work. Trace Compass could also unescape packet context
member names, but it will be faster to do this in Babeltrace 2 and it
will match the LTTng behaviour more closely.

>
> I tried fixing this with the attached patch,

If you need comments on a patch, even if it's an RFC, please prefer
Gerrit so that we can comment specific lines and follow the discussion
more easily.

BR,

Philippe