From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Ingham <jingham@apple.com>
Cc: GDB Patches <gdb-patches@sources.redhat.com>
Subject: Re: Bug with lists in tables in ui-out.c
Date: Tue, 04 Dec 2001 23:05:00 -0000 [thread overview]
Message-ID: <3C0DC70E.6090607@cygnus.com> (raw)
In-Reply-To: <B82AD27E.3211%jingham@apple.com>
> Hi all,
This code my head hurt.
> 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.
Can this be fixed in a simpler cleaner way by just moving the table
stuff into `struct ui_out_level'?
When I was last working on this code I very nearly did just this change :-/
enjoy,
Andrew
> Note that in the FSF gdb code, no one ever uses this feature, because the
> only client of the ui_out_table is the breakpoint printer, and it cleverly
> only declares the first 5 or 6 columns of the breakpoint info table in the
> table header, and sticks on the rest of the info as undeclared freebies
> (which is kind of lame, but another story...), so the commands, which are a
> list, don't get added to the table proper, and thus don't trip the bug.
>
> I have a patch which will fix this and make the table header accurate, but I
> am not submitting it here because (a) it is a separate issue and (b) it will
> change the output of the "info breakpoint" command (though only the header),
> and so may not necessarily please everyone...
>
> Jim
>
> Index: ui-out.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/ui-out.c,v
> retrieving revision 1.18
> diff -p -r1.18 ui-out.c
> *** ui-out.c 2001/07/06 03:53:11 1.18
> --- ui-out.c 2001/11/29 01:40:59
> *************** ui_out_end (struct ui_out *uiout,
> *** 367,372 ****
> --- 367,384 ----
> enum ui_out_type type)
> {
> int old_level = pop_level (uiout, type);
> +
> + /* If we are building up a table, and we were making a table element
> + which was a list or tuple, then when we end the list, we have to
> + increment the header. Watch out, however, the current breakpoint
> + code actually emits more columns than it defines in the header
> + so we have to be careful not to walk off the end. */
> +
> + if (uiout->table_flag && uiout->body_flag
> + && uiout->level == 1
> + && uiout->headercurr != NULL)
> + uiout->headercurr = uiout->headercurr->next;
> +
> uo_end (uiout, type, old_level);
> }
>
> *************** append_header_to_list (struct ui_out *ui
> *** 1018,1024 ****
> uiout->headercurr = uiout->headerlast;
> }
>
> ! /* returns 0 if there is no more headers */
>
> static int
> get_curr_header (struct ui_out *uiout,
> --- 1030,1038 ----
> uiout->headercurr = uiout->headerlast;
> }
>
> ! /* Returns information on the current header. ALSO Increments the
> ! current header in UI_OUT. Returns 0 if there is no more headers, 1
> ! otherwise. */
>
> static int
> get_curr_header (struct ui_out *uiout,
> *************** specified after table_body and inside a
> *** 1056,1062 ****
> }
> }
>
> ! /* determines what is the alignment policy */
>
> static void
> verify_field_alignment (struct ui_out *uiout,
> --- 1070,1079 ----
> }
> }
>
> ! /* Determines what is the alignment policy. NB: as a side-effect of
> ! calling get_curr_header, this also increments the current header. So
> ! you have to call verify_field_alignment in any call that adds a
> ! complete bit of data to a table column. */
>
> static void
> verify_field_alignment (struct ui_out *uiout,
> *************** verify_field_alignment (struct ui_out *u
> *** 1066,1073 ****
> {
> int colno;
> char *text;
>
> ! if (uiout->table_flag
> && get_curr_header (uiout, &colno, width, align, &text))
> {
> if (fldno != colno)
> --- 1083,1097 ----
> {
> int colno;
> char *text;
> +
> + /* Be careful - if you are building up a list or tuple AS AN ELEMENT
> + of a table, you don't want to call get_curr_header, since that will
> + increment the current header, which would be wrong. Currently, tables
> + can only be built at level 1, so I am using that as a check. If this
> + stuff is ever generalized, we will need to stuff the level of the
> + current table into the (putative) ui_table structure. */
>
> ! if (uiout->table_flag && uiout->level == 1
> && get_curr_header (uiout, &colno, width, align, &text))
> {
> if (fldno != colno)
>
>
next prev parent reply other threads:[~2001-12-05 7:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-28 17:42 Jim Ingham
2001-11-18 11:04 ` Jim Ingham
2001-11-29 0:20 ` Eli Zaretskii
2001-11-19 11:24 ` Eli Zaretskii
2001-12-03 13:49 ` Jim Ingham
2001-12-04 0:08 ` Eli Zaretskii
2001-12-04 23:05 ` Andrew Cagney [this message]
2001-12-04 23:36 ` Andrew Cagney
2001-12-05 11:59 ` Jim Ingham
2001-12-06 15:06 ` Andrew Cagney
2001-12-06 16:41 ` Jim Ingham
2001-12-07 11:01 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C0DC70E.6090607@cygnus.com \
--to=ac131313@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jingham@apple.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox