Re: decoding tracef msg string via babeltrace API

[Milian Wolff via lttng-dev <lttng-dev@lists.lttng.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3292 bytes --]

On Wednesday, April 10, 2019 9:56:43 AM CEST Milian Wolff wrote:
> On Tuesday, April 9, 2019 7:02:06 PM CEST Jérémie Galarneau wrote:
> > On Tue, 9 Apr 2019 at 04:36, Milian Wolff <milian.wolff@kdab.com> wrote:
> > > On Thursday, April 4, 2019 8:25:51 PM CEST Jérémie Galarneau wrote:
> > > > Hi Milian,
> > > > 
> > > > I have pushed a fix [1] in the stable-1.5 branch that addresses the
> > > > issue you have encountered with using bt_ctf_get_field_list().
> > > > This makes it possible to consume a character sequence's content.
> > > > 
> > > > The commit message contains an example to show how to essentially
> > > > perform what the 'ctf-text' format plug-in achieves by accessing the
> > > > internal string field.
> > > > 
> > > > Let me know if that works for you and I'll release an updated version
> > > > of the 1.5 branch.
> > > 
> > > Thank you, I'll try that out in the next days!
> > > 
> > > But: why can't we make bt_ctf_get_string return the string for us? Why
> > > do
> > > we
> > > need to reinvent the wheel in consumers of the babeltrace API? You point
> > > out
> > 
> > Hi,
> > 
> > Strings, sequences and arrays are three different types in CTF.
> > 
> > bt_ctf_get_string() can only be used on CTF strings. In the babeltrace 1.x
> > API, those are expressed through 'bt_definition's that have a
> > 'bt_declaration'
> > of type CTF_TYPE_STRING. It is not a general-purpose accessor to get
> > a field's content as a C-string.
> > 
> > Changing this in the 1.x release series goes against the design of the
> > API (dedicated functions per definition type) and would, arguably, be an
> > ABI breaking change.
> > 
> > As pointed out in the commit message, bt_ctf_get_char_array() is
> > a convenience function to access a character-array's contents as
> > a C-string. An equivalent function could be added for sequences.
> > 
> > Since you pointed-out a bug in the existing API, my priority was
> > in fixing that bug which prevented users from accessing the sequences'
> > contents at all in the "looks like a string" case. That fix can be
> > back-ported into existing releases and made available in a point-release.
> > 
> > Adding new APIs is an orthogonal concern. I'm not against a
> > convenience function that does what you want; but it won't be
> > shoe-horned into an existing one.
> 
> I see. I'll have to live with this, but note how the current situation is
> far from perfect:
> 
> There's no way to figure out the exact version of babeltrace, neither at
> compile nor at runtime. So any user of babeltrace will potentially crash
> when calling bt_ctf_get_field_list to read a string-sequence.

Additionally, the suggested approach of iterating over the individual chars in 
the sequence doesn't allow for a zero-copy approach as is done with 
bt_ctf_get_char_array or bt_ctf_get_string.

Both could be solved if a bt_ctf_get_string_sequence or similar would be 
introduced. Would this be accepted upstream, if I create a pull request, or is 
1.5 frozen and no new API is allowed to be added?

Thanks

-- 
Milian Wolff | milian.wolff@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3826 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev