Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Sergio Durigan Junior <sergiodj@redhat.com>,
	Jan Kratochvil	<jan.kratochvil@redhat.com>, <gdb@sourceware.org>
Subject: Re: Switch -Wunused-variable on?
Date: Tue, 24 Apr 2012 22:11:00 -0000	[thread overview]
Message-ID: <alpine.DEB.1.10.1204242254130.19835@tp.orcam.me.uk> (raw)
In-Reply-To: <87sjfufrlr.fsf@fleche.redhat.com>

On Mon, 23 Apr 2012, Tom Tromey wrote:

> I'd say that the best approach would be to make the declarations
> conditional in the same way that the uses are.
> 
> If there are a lot of problem cases with this approach, or if it makes
> the code too ugly, then maybe it would be better just not to use this
> flag.

 That IMHO just asks to refrain from interspersing function bodies with 
preprocessor conditionals.  Lots if not all conditional stuff can be 
factored out to headers or definitions elsewhere.  Linux the kernel for 
one has had such a policy for years now.

 Example.  Do not write this:

int target_frobnicate (int count);

#ifdef TARGET_NEEDS_HARD_FROBNICATION
int target_frobnicate_harder (int count, int status);
#endif

int
handle_frobnication (int count)
{
  int status;
  int i;

  status = target_frobnicate (count);
#ifdef TARGET_NEEDS_HARD_FROBNICATION
  for (i = 0; i < count; i++)
    status = target_frobnicate_harder (i, status);
#endif

  return status;
}

Instead write this:

int target_frobnicate (int count);

#ifdef TARGET_NEEDS_HARD_FROBNICATION
int target_frobnicate_harder (int count, int status);
#define target_needs_hard_frobnication 1
#else
#define target_needs_hard_frobnication 0
endif

int
handle_frobnication (int count)
{
  int status;
  int i;

  status = target_frobnicate (count);
  if (target_needs_hard_frobnication)
    for (i = 0; i < count; i++)
      status = target_frobnicate_harder (i, status);

  return status;
}

-- "i" is now live in all cases and also IMHO handle_frobnication is more 
readable.

  Maciej


  parent reply	other threads:[~2012-04-24 22:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-22  8:06 Sergio Durigan Junior
2012-04-22  8:23 ` Jan Kratochvil
2012-04-22 20:25   ` Sergio Durigan Junior
2012-04-22 22:25     ` Jeffrey Walton
2012-04-23  8:55       ` Jan Kratochvil
2012-04-23 14:30     ` Tom Tromey
2012-04-23 15:49       ` Sergio Durigan Junior
2012-04-23 18:02         ` Pedro Alves
2012-04-23 18:39           ` Michael Eager
2012-04-24 22:11       ` Maciej W. Rozycki [this message]
2012-04-25  7:51         ` Andreas Schwab
2012-04-25 15:57           ` Maciej W. Rozycki
2012-04-25 16:50             ` Andreas Schwab
2012-04-25 17:22               ` Maciej W. Rozycki
2012-04-25 18:13                 ` Andreas Schwab
2012-04-25 18:20                   ` Sterling Augustine
2012-04-25 18:52                     ` Maciej W. Rozycki

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=alpine.DEB.1.10.1204242254130.19835@tp.orcam.me.uk \
    --to=macro@codesourcery.com \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=sergiodj@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