This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] (cli/cli-cmds.c) ARI fix: Avoid assignment inside if statement
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: Eli Zaretskii <eliz at gnu dot org>, Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>, gdb-patches at sourceware dot org
- Date: Mon, 24 Dec 2012 08:11:16 +0400
- Subject: Re: [RFA] (cli/cli-cmds.c) ARI fix: Avoid assignment inside if statement
- References: <001201cde13f$af3ad4b0$0db07e10$%muller@ics-cnrs.unistra.fr> <837go8pnxn.fsf@gnu.org> <m3fw2wo12z.fsf@redhat.com>
> > Since when is that bad C, so much so that we would need to enforce it?
>
> Interesting... I remember when I started hacking GDB, I was strongly
> discouraged to do assignments inside `if' checkings. I don't remember
> who told me that, but the reason was something related to the Coding
> Standards (I don't have any references either). Anyway, since that
> moment I stopped doing this...
It is in the GNU Coding Standards:
http://www.gnu.org/prep/standards/standards.html#Syntactic-Conventions
In particular:
| Try to avoid assignments inside if-conditions (assignments inside
| while-conditions are ok). For example, donâ??t write this:
|
| if ((foo = (char *) malloc (sizeof *foo)) == 0)
| fatal ("virtual memory exhausted");
| instead, write this:
|
| foo = (char *) malloc (sizeof *foo);
| if (foo == 0)
| fatal ("virtual memory exhausted");
FWIW, I mostly agree with this suggestion, particulary in the
examples above. I do remember seeing some examples where it was
more practical if we could have assignments inside conditions
(in an "if ... else if ..." situation), but even then, I find
that it makes it harder to notice the assignment.
In the examples that Pierre chose to fix, it seems obvious to me
(this is a judgement call, so potentially subject to disagreement)
that there was no need to have the assignment inside the condition,
and that the patched code is easier to grasp. I think it is
a clear improvement.
> FWIW, I agree that it is not bad C, and totally valid
I think that the point is not that this is bad C, or not
valid/portable. I think that the point is that it is judged
to be a poor practice.
--
Joel