From: Simon Marchi <simon.marchi@ericsson.com>
To: Mark Wielaard <mjw@redhat.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix GCC6 -Wmisleading-indentation issues.
Date: Mon, 25 Jan 2016 21:46:00 -0000 [thread overview]
Message-ID: <56A697A2.9060207@ericsson.com> (raw)
In-Reply-To: <1453750851-29990-1-git-send-email-mjw@redhat.com>
On 16-01-25 02:40 PM, Mark Wielaard wrote:
> GCC6 will warn about misleading indentation issues like:
>
> gdb/ada-lang.c: In function ‘ada_evaluate_subexp’:
> ada-lang.c:11423:9: error: statement is indented as if it were guarded by...
> arg1 = unwrap_value (arg1);
> ^~~~
>
> gdb/ada-lang.c:11421:7: note: ...this ‘else’ clause, but it is not
> else
> ^~~~
>
> In this case it would be a bug except for the fact the if clause already
> returned early. So this misindented statement really only got executed
> for the else case. But it could easily mislead a reader, so adding a
> proper else block is the correct solution.
>
> In case of c-typeprint.c (c_type_print_base) the if statement is indeed
> misleadingly indented, but not a bug. Just indent correctly. The inflow.c
> (terminal_ours_1) misindented block comes from the removal of an if clause
> in commit d9d2d8b which looks correct. So just reindent the brackets of
> the block. The linux-record.c misleadingly indented return statements
> are just that. Misleading to the reader, but not actual bugs. So just
> properly indent them so they don't look the fall under the wrong if clause.
Thanks for doing this!
If you feel like it, you could build with --enable-targets=all to enable more code.
You'll find more of these.
One little comment below, otherwise it LGTM (without implying that my voice is
worth anything).
> diff --git a/gdb/inflow.c b/gdb/inflow.c
> index bbd2b12..d1dd41c 100644
> --- a/gdb/inflow.c
> +++ b/gdb/inflow.c
> @@ -413,7 +413,7 @@ child_terminal_ours_1 (int output_only)
> if (tinfo->run_terminal != NULL || gdb_has_a_terminal () == 0)
> return;
>
> - {
> + {
> #ifdef SIGTTOU
> /* Ignore this signal since it will happen when we try to set the
> pgrp. */
> @@ -497,7 +497,7 @@ child_terminal_ours_1 (int output_only)
> result = fcntl (0, F_SETFL, our_terminal_info.tflags);
> result = fcntl (0, F_SETFL, our_terminal_info.tflags);
> #endif
> - }
> + }
Shouldn't the code inside the brackets be de-indented too?
next prev parent reply other threads:[~2016-01-25 21:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 19:41 Mark Wielaard
2016-01-25 21:46 ` Simon Marchi [this message]
2016-01-25 22:14 ` Mark Wielaard
2016-01-25 22:24 ` Pedro Alves
2016-01-25 22:38 ` Mark Wielaard
2016-01-25 23:00 ` Pedro Alves
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=56A697A2.9060207@ericsson.com \
--to=simon.marchi@ericsson.com \
--cc=gdb-patches@sourceware.org \
--cc=mjw@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