From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8002 invoked by alias); 18 Mar 2004 05:53:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7885 invoked from network); 18 Mar 2004 05:53:13 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 18 Mar 2004 05:53:13 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.30) id 1B3qRs-0007MX-8T; Thu, 18 Mar 2004 00:52:08 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 Message-Id: From: Eli Zaretskii To: Jason Molenda CC: cagney@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <6994FFF8-786D-11D8-9229-000393D457E2@apple.com> (message from Jason Molenda on Wed, 17 Mar 2004 15:47:12 -0800) Subject: Re: RFC patch mi-cmds.c table format (pedantic) Reply-to: Eli Zaretskii References: <6994FFF8-786D-11D8-9229-000393D457E2@apple.com> X-SW-Source: 2004-03/txt/msg00418.txt.bz2 > From: Jason Molenda > Date: Wed, 17 Mar 2004 15:47:12 -0800 > > As you can see here, the use of 0 vs NULL is inconsistent, and the=20 > spacing on the close parens on the last arg is inconsistent. The=20 > implied initialization of 0 is also used in many places. All of this=20 > is valid, but it could be a bit more consistent. So instead of > > - { "break-insert", { NULL, 0 }, 0, mi_cmd_break_insert}, > + { "break-insert", { NULL, 0 }, NULL, mi_cmd_break_insert}, > > - { "exec-step", { NULL, 0 }, mi_cmd_exec_step}, > + { "exec-step", { NULL, 0 }, mi_cmd_exec_step, NULL}, > > - { NULL, } > + { NULL, { NULL, 0 }, NULL, NULL} Don't these changes require changes to the GDB/MI documentation in gdb.texinfo? IIRC, there are examples there to what each command outputs. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8002 invoked by alias); 18 Mar 2004 05:53:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7885 invoked from network); 18 Mar 2004 05:53:13 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 18 Mar 2004 05:53:13 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.30) id 1B3qRs-0007MX-8T; Thu, 18 Mar 2004 00:52:08 -0500 Date: Thu, 18 Mar 2004 05:53:00 -0000 Message-ID: From: Eli Zaretskii To: Jason Molenda CC: cagney@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <6994FFF8-786D-11D8-9229-000393D457E2@apple.com> (message from Jason Molenda on Wed, 17 Mar 2004 15:47:12 -0800) Subject: Re: RFC patch mi-cmds.c table format (pedantic) Reply-to: Eli Zaretskii References: <6994FFF8-786D-11D8-9229-000393D457E2@apple.com> X-SW-Source: 2004-03.o/txt/msg00418.txt Message-ID: <20040318055300.j6VS96cWSdLBep3sVJ9by0PsO-vIItbFJJtEfCtRmW4@z> > From: Jason Molenda > Date: Wed, 17 Mar 2004 15:47:12 -0800 > > As you can see here, the use of 0 vs NULL is inconsistent, and the=20 > spacing on the close parens on the last arg is inconsistent. The=20 > implied initialization of 0 is also used in many places. All of this=20 > is valid, but it could be a bit more consistent. So instead of > > - { "break-insert", { NULL, 0 }, 0, mi_cmd_break_insert}, > + { "break-insert", { NULL, 0 }, NULL, mi_cmd_break_insert}, > > - { "exec-step", { NULL, 0 }, mi_cmd_exec_step}, > + { "exec-step", { NULL, 0 }, mi_cmd_exec_step, NULL}, > > - { NULL, } > + { NULL, { NULL, 0 }, NULL, NULL} Don't these changes require changes to the GDB/MI documentation in gdb.texinfo? IIRC, there are examples there to what each command outputs.