This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH RFC] Protoize m32r-stub.c, m88k-nat.c, m88k-tdep.c
- To: jtc at redback dot com
- Subject: Re: [PATCH RFC] Protoize m32r-stub.c, m88k-nat.c, m88k-tdep.c
- From: Stan Shebs <shebs at apple dot com>
- Date: Fri, 15 Sep 2000 11:04:15 -0700
- CC: Kevin Buettner <kevinb at cygnus dot com>, gdb-patches at sourceware dot cygnus dot com
- References: <1000915073306.ZM4195@ocotillo.lan> <5mk8cdzgri.fsf@jtc.redback.com>
"J.T. Conklin" wrote:
>
> >>>>> "Kevin" == Kevin Buettner <kevinb@cygnus.com> writes:
> Kevin> I did three files this time because there was only one function that
> Kevin> needed doing in each of them. (The m88k-*.c files bring back old
> Kevin> memories; I first started hacking on gdb on an m88k box in the early
> Kevin> nineties.)
> Kevin>
> Kevin> * m32r-stub.c (prepare_to_step): Protoize.
>
> Should we consider not protoizing the *-stub.c files? While these are
> distributed with GDB, they are code that is going to be hacked to bits
> as they are integrated into a remote target. While user is probably
> using gcc, it may be reasonable to be as conservative we can when it
> comes to these files...
It's a pretty safe bet that all m32r compilers are ISO! I thought
about the stub code standard a while back, and concluded that since
the stubs are effectively example code, they at least ought to be
*good* examples. In fact, they're probably the most-looked-at sources
in the whole GDB tree, so they should be exemplars of our recommended
coding practices (suitably adjusted for the embedded case of course).
Stan