From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23954 invoked by alias); 9 May 2012 13:54:18 -0000 Received: (qmail 23943 invoked by uid 22791); 9 May 2012 13:54:16 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ausc60ps301.us.dell.com (HELO ausc60ps301.us.dell.com) (143.166.148.206) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 May 2012 13:53:59 +0000 X-Loopcount0: from 10.170.28.41 From: To: CC: , , Subject: Re: [RFA] Emit a warning for ineffective set VAR = EXP command Date: Wed, 09 May 2012 13:54:00 -0000 Message-ID: <46C50B2C-7910-4B36-B64B-D1C6C91627B8@dell.com> References: <8781499A-A489-42D0-80B1-75136331DBDB@adacore.com> <20120507193824.GW15555@adacore.com> <419AD66E-6D21-40D6-97FE-1FF387117B7D@adacore.com> In-Reply-To: <419AD66E-6D21-40D6-97FE-1FF387117B7D@adacore.com> Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00267.txt.bz2 On May 9, 2012, at 8:28 AM, Tristan Gingold wrote: >=20 > On May 7, 2012, at 9:38 PM, Joel Brobecker wrote: >=20 >>>> This warns about "set variable $j++" presumably -- should the warning = be=20 >>>> disabled for pre/post increments/decrements? >>>=20 >>> I am not opposed to disable warnings for pre/post inc/dec. >>> But this usage is dubious (the help explicitly mentions VAR=3DEXP !) >>>=20 >>> Opinion ? >>=20 >> I think we should avoid the warning for pre/post inc/dec. This >> type of expression might be a little outside the method proposed >> in our documentation, but I think it's still a perfectly valid >> expression that results in an assignment being performed. >=20 > I don't know who should approve this adjustment, but here is the version = that deals with pre/post inc/dec. > Note that it still warns for expressions such as i++ * 2. If you had it walk through the elts[] list, would it then work for that cas= e? paul >=20 > Tested on set-nowarns.exp. >=20 > Tristan. >=20 > 2012-05-09 Tristan Gingold >=20 > * printcmd.c (set_command): Add pre/post inc/dec. >=20 > diff --git a/gdb/printcmd.c b/gdb/printcmd.c > index 79e38f2..fa76296 100644 > --- a/gdb/printcmd.c > +++ b/gdb/printcmd.c > @@ -1080,11 +1080,21 @@ set_command (char *exp, int from_tty) > struct cleanup *old_chain =3D > make_cleanup (free_current_contents, &expr); >=20 > - if (expr->nelts >=3D 1 > - && expr->elts[0].opcode !=3D BINOP_ASSIGN > - && expr->elts[0].opcode !=3D BINOP_ASSIGN_MODIFY > - && expr->elts[0].opcode !=3D BINOP_COMMA) > - warning (_("Expression is not an assignment (and might have no effec= t)")); > + if (expr->nelts >=3D 1) > + switch (expr->elts[0].opcode) > + { > + case UNOP_PREINCREMENT: > + case UNOP_POSTINCREMENT: > + case UNOP_PREDECREMENT: > + case UNOP_POSTDECREMENT: > + case BINOP_ASSIGN: > + case BINOP_ASSIGN_MODIFY: > + case BINOP_COMMA: > + break; > + default: > + warning > + (_("Expression is not an assignment (and might have no effect)")); > + } >=20 > evaluate_expression (expr); > do_cleanups (old_chain); >=20