Re: Bug with lists in tables in ui-out.c

[Jim Ingham <jingham@apple.com>]

On 12/4/01 11:36 PM, "Andrew Cagney" <ac131313@cygnus.com> wrote:

>> Turns out if you have an element of a table that is a list or tuple, then
>> the current ui-out table code chokes.  verify_field_alignment doesn't know
>> that each of the elements of the sublist are not separate table elements, so
>> it throws an error at the first one it sees.  The following patch fixes this
>> bug. 
> 
> Thinking about this some more, I suspect you're constructing something like:
> 
> table={hdr={...},body=[{{<THIS>}, ...},...}]}
> 
> or as a code sequence:
> 
> ..._body()
>  ui_out_tuple_begin(); /*row*/
>    ui_out_tupple_begin(); /* element - non-standard */
>      ui_out_field (...<THIS>..)
> 
> I'm wondering if a table is even applicable in this case.  How exactly
> should the header formatting information, for instance, be interpreted
> when there is more than one entry.
> 
> Would you have an example?
> 
> Andrew
> 
> 
> 

Andrew,

The example is the table that "info break" makes.  In FSF gdb, you only emit
table headers for the first 6 columns, and if there are commands, they are
added to the bkpt tuple (and so formally should be other columns in the
table), but there is no equivalent entry in the header list.  The table code
doesn't require that all data in a table row have an equivalent header
entry, so this works, but this is just a bit bogus...  Somebody here got
annoyed by this and added table headers for the other columns - mostly so
users could see what the columns mean.  In this case, the list that is being
added to the table is the list of breakpoint commands.

Jim
-- 
+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==
Jim Ingham                              jingham@apple.com
Developer Tools - gdb