> On Oct 7, 2020, at 11:44 AM, Pavel Labath <pa...@labath.sk> wrote:
>
> On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
>> There isn’t a built-in summary formatter for two dimensional arrays of
>> chars, but the type is matching the regex for the one-dimensional
>> StringSummaryFormat, but that doesn’t actually know how to format two
>> dimensional arrays of chars. The type regex for StringSummaryFormat:
>> char [[0-9]+]
>> We should refine this regex so it doesn’t catch up two dimensional strings.
>> We could also write a formatter for two-dimensional strings.
>
> Do we need a special formatter for two-dimensional strings? What about 3D?
>
> I'd hope that this could be handled by a combination of the simple string
> formatter and the generic array dumping code...
That works as expected, for instance if you do:
(lldb) frame var z.i
(char [2][4]) z.i = {
[0] = "FOO"
[1] = "BAR"
}
The thing that isn’t working is when the array doesn’t get auto-expanded by
lldb, then you see the summary instead, which is what you are seeing with:
(lldb) frame var z
(b) z = (i = char [2][4] @ 0x00007ffeefbff5f0)
You can fix this either by having a summary string for char [][] or by telling
lldb to expand more pointer like children for you:
(lldb) frame var -P2 z
(b) z = {
i = {
[0] = "FOO"
[1] = "BAR"
}
}
I’m hesitant to up the default pointer depth, I have gotten lots of complaints
already about lldb disclosing too many subfields when printing structures.
We could also try to be smarter about what constitutes a “pointer” so the
arrays don’t count against the pointer depth? Not sure how workable that would
be.
Jim
>
> pl
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
