[Q] Bit field/array/pointer output formatting disambiguation

[Zhibin Li]

Just got a question about this. If it's meant to break those assumptions or
whatever expectations from someone, why not make the output more explicit
(e.g. add some annotations like:
        getgroups(32, array[100, 0]) = 2
        sigprocmask(SIG_BLOCK, bitset[CHLD TTOU], []) = 0
or any abbreviations of array and bitset instead of just adding spaces
around those elements, which makes them literarily distinguishable but still
a little confusing when someone glances at it. Of course this idea makes
the
output more complicated and I'm not sure about its feasibility. Anyway, I'm
willing to discuss and help :).

Zhibin Li

On Wed, Oct 17, 2018 at 12:13 PM Eugene Syromyatnikov <evgsyr at gmail.com>
wrote:

> Hello.
>
> There are some questions about strace users' preference regarding
> formatting of bit fields, arrays, and pointers in strace's output. As
> of now, square brackets are used for designating all these things,
> with the only difference in a separator used for delimiting items in
> arrays and bit masks (a combination of comma and space is used for
> delimiting array items, and a space is used for bit fields). Examples
> from strace(1):
>            getgroups(32, [100, 0]) = 2
>            sigprocmask(SIG_BLOCK, [CHLD TTOU], []) = 0
>
> A special case of an array is a pointer reference, which is also
> printed using square brackets:
>            futex([0x2] /* 0x7fbf7bd730c8 */, FUTEX_WAKE_PRIVATE,
> 2147483647) = 0
>
> The issue is that an array that contains only a single item may be
> confused with a bit mask that has only one bit set. As a solution to
> this, it is proposed to add spaces around elements in bit mask output:
>            getgroups(32, [100]) = 2
>            getgroups(32, []) = 2
>            sigprocmask(SIG_BLOCK, [ CHLD ], [  ]) = 0
>            sigprocmask(SIG_UNBLOCK, ~[  ], NULL) = 0
>
> The main problem associated with that change is that It breaks
> established output formatting rules that are likely being relied upon
> by some. Other significant problem is within the fact that such kind
> of output formatting is somewhat unorthodox (having syntactically
> significant whitespace).
>
> The other slightly relevant issue is that, as of now, there is no
> distinction in the formatting of structures that are referenced by
> pointer compared to embedded structures (e.g., no difference of fields
> A and B in the output of the following structure: struct { struct
> timespec *A; struct timespec B; };); it is proposed to print square
> brackets around structures that are referenced by pointer, and the
> issue is the same: it will change a lot of exiting output and likely
> will break a lot of assumptions.
>
> The solution I can see is to add an option that enables more regular
> output, but that would be yet another option some have to pass for
> each interactive strace session, and will create the need to have
> significant amount of code for handling both legacy and regular output
> formatting, which doesn't really help maintainability of the project.
>
> So, maybe someone has any ideas in this regard (a completely different
> syntax for bit sets that considers the fact that there are stripped
> prefixes for bit constants, for example)?
>
> --
> Eugene Syromyatnikov
> mailto:evgsyr at gmail.com
> xmpp:esyr at jabber.{ru|org}
> --
> Strace-devel mailing list
> Strace-devel at lists.strace.io
> https://lists.strace.io/mailman/listinfo/strace-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20181023/5c93bcf2/attachment.html>