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.wo...@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.wo...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev