Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>,
	gdb-patches <gdb-patches@sourceware.org>,
		Pedro Alves <palves@redhat.com>
Subject: Re: [PATCH] Fix Gold/strip discrepancies for PR 11786
Date: Wed, 06 Nov 2013 21:16:00 -0000	[thread overview]
Message-ID: <CADPb22S4ivEm=abcrxLBQwiB9yrB7CryvOBNi+rh-GdOpek5nQ@mail.gmail.com> (raw)
In-Reply-To: <20131105180547.GA24004@host2.jankratochvil.net>

On Tue, Nov 5, 2013 at 10:05 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 05 Nov 2013 18:56:29 +0100, Doug Evans wrote:
>> If the decision is to be more strict with the rules for testcases
>> that's fine by me.
>> Let's write it down, then discussions like these will become a *lot* shorter.
>
> Adding more and more rules I do not find as a clear win.
> When I code GDB I have to think about so many established non-standard coding
> style rules my head is going to explode.  Switching between multiple projects
> each having different coding style makes it worse.
>
> But sending a patch and getting it corrected here and there due to unwritten
> rules one could not find anywhere is also not great, though, I agree.

At the end of the day I'm still lacking the clarity I seek.
[It's not imperative, but it's more than "IWBN".]

I'm not suggesting adding more rules (per se), but I do think there's
no downside to writing down existing unwritten rules (for those things
that are, indeed, rules).

I'm going to propose the following, and if y'all are ok with it then
this can be the end of it, this thread is done.

If there are no objections, I will add a Testsuite section to the
C-Coding-Standards section of the wiki:
https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards

It will basically say tests are in general not required to following
the GDB coding standards,
but there are a few exceptions, and then have an enumeration of explicit rules,
and for now just have the one: (void) is required over ().
And for grin's sake, since there's so many of them, and less likely to
be a problem, int main () is ok.
I'll also mention that "Monkey See Monkey Do hacking should generally
Just Work."
[There's less need to go into detail if one can say one can just mimic
existing code.
That will keep it short-and-sweet.
I'm ok with people adding more to the wiki, but I like taking "baby steps".]

I'll probably also add a link to the new section to:
https://sourceware.org/gdb/wiki/GDBTestcaseCookbook


  reply	other threads:[~2013-11-06 21:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25 23:26 Doug Evans
2013-10-30 23:57 ` Doug Evans
2013-10-31 16:42 ` Jan Kratochvil
2013-11-04 22:38   ` Doug Evans
2013-11-04 23:04     ` Cary Coutant
2013-11-05  3:42     ` Tom Tromey
2013-11-05 17:22       ` Doug Evans
2013-11-05 17:23         ` Jan Kratochvil
2013-11-05 18:01           ` Doug Evans
2013-11-05 18:13             ` Jan Kratochvil
2013-11-06 21:16               ` Doug Evans [this message]
2013-11-06 21:28                 ` Jan Kratochvil
2013-11-07  1:05                   ` Stan Shebs
2013-11-07 18:01                   ` Doug Evans
2013-11-07 19:03                     ` Jan Kratochvil
2013-11-08 17:57                       ` Doug Evans
2013-11-08 19:17                         ` Jan Kratochvil
2013-11-12 18:46                           ` Doug Evans
2013-11-12 19:58                             ` Jan Kratochvil
2013-11-12 22:05                               ` Doug Evans
2013-11-05 17:32         ` Tom Tromey
2013-11-05 17:32         ` Pedro Alves
2013-11-05 17:04     ` Jan Kratochvil

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='CADPb22S4ivEm=abcrxLBQwiB9yrB7CryvOBNi+rh-GdOpek5nQ@mail.gmail.com' \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=palves@redhat.com \
    --cc=tromey@redhat.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