This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix Gold/strip discrepancies for PR 11786
- From: Doug Evans <dje at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>, Cary Coutant <ccoutant at google dot com>
- Date: Tue, 5 Nov 2013 09:04:38 -0800
- Subject: Re: [PATCH] Fix Gold/strip discrepancies for PR 11786
- Authentication-results: sourceware.org; auth=none
- References: <yjt24n85x78h dot fsf at ruffy dot mtv dot corp dot google dot com> <20131031154957 dot GA11260 at host2 dot jankratochvil dot net> <CADPb22QKBpYpmmZzeKJy7JWukpfkTQcYZDm+KeEkr6K_92LJ2A at mail dot gmail dot com> <87li13shk2 dot fsf at fleche dot redhat dot com>
On Mon, Nov 4, 2013 at 6:34 PM, Tom Tromey <tromey@redhat.com> wrote:
>>> (void)
>
> Doug> We don't have any such style rules for testcases.
> Doug> But ok, done.
>
> Doug> Going forward though, for my own patch reviews of other people's code,
> Doug> what's the story here?
>
> In this case, "()" is not idiomatic C, whereas "(void)" is.
> This is not the same as a coding style rule.
I'm not sure how to read this.
Is this an argument for requiring (void) in all testsuite C function
definitions?
It's ok by me, but it seems to me it's not a requirement today as
there are plenty of existing examples, including recent ones. OTOH,
if there is such a requirement we'd better get it written down so we
can refer to it when requesting corrections in patches, and so people
can know ahead of time what's expected. Obviously the rules state
this for gdb itself, but it's been my understanding that these rules
explicitly do not apply to the testsuite, and this understanding has
been affirmed from time to time. All I'm asking for is clarity and
consistency.
Or is this just a point about a bad use of the word "style"?
By itself "style" is a pretty nondescript word.
Alas I'm not one for always assigning names with precision.
If this isn't a style issue, coding *or* otherwise, let me know what to call it.
If this is something else, let me know that too. :-)