From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3906 invoked by alias); 9 May 2012 14:10:22 -0000 Received: (qmail 3889 invoked by uid 22791); 9 May 2012 14:10:20 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 May 2012 14:09:51 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 4845C29000E; Wed, 9 May 2012 16:09:56 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCmILGMnqXtI; Wed, 9 May 2012 16:09:56 +0200 (CEST) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id E0133290008; Wed, 9 May 2012 16:09:55 +0200 (CEST) Subject: Re: [RFA] Emit a warning for ineffective set VAR = EXP command Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tristan Gingold In-Reply-To: <46C50B2C-7910-4B36-B64B-D1C6C91627B8@dell.com> Date: Wed, 09 May 2012 14:10:00 -0000 Cc: , , Content-Transfer-Encoding: quoted-printable Message-Id: References: <8781499A-A489-42D0-80B1-75136331DBDB@adacore.com> <20120507193824.GW15555@adacore.com> <419AD66E-6D21-40D6-97FE-1FF387117B7D@adacore.com> <46C50B2C-7910-4B36-B64B-D1C6C91627B8@dell.com> To: 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/msg00268.txt.bz2 On May 9, 2012, at 3:53 PM, w= rote: >=20 > On May 9, 2012, at 8:28 AM, Tristan Gingold wrote: >=20 >>=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. >=20 > If you had it walk through the elts[] list, would it then work for that c= ase? Is it worth the burden ? >=20 > paul >=20 >>=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 effe= ct)")); >> + 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 >=20