> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > > >> On Oct 7, 2020, at 12:11 PM, Pavel Labath <pa...@labath.sk> wrote: >> >> On 07/10/2020 21:01, Jim Ingham wrote: >>>> On Oct 7, 2020, at 11:44 AM, Pavel Labath <pa...@labath.sk >>>> <mailto: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, >> >> Ah, interesting. I didn't realize that. >> >>> 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. >> >> Yeah, I don't think we'd want to increase that. >> >>> 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. >> >> This sounds workable. I mean, an array struct member is not really a pointer >> (it only decays to a pointer) and does not suffer from the issues that >> pointers do -- infinite recursion with recursive data structures, etc. > > In any case we should not have the simple string formatter trying to format > these arrays, which it clearly doesn’t know how to do.
Should be easy to modify the regex to: ^char \[[0-9]+\]$
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
