From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:34888)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QpRdX-00058T-Jx
	for qemu-devel@nongnu.org; Fri, 05 Aug 2011 17:08:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QpRdW-0004H4-FZ
	for qemu-devel@nongnu.org; Fri, 05 Aug 2011 17:08:55 -0400
Received: from mail-yw0-f45.google.com ([209.85.213.45]:40669)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QpRdW-0004H0-Ay
	for qemu-devel@nongnu.org; Fri, 05 Aug 2011 17:08:54 -0400
Received: by ywb3 with SMTP id 3so2240297ywb.4
	for <qemu-devel@nongnu.org>; Fri, 05 Aug 2011 14:08:53 -0700 (PDT)
Message-ID: <4E3C5BE2.8030500@codemonkey.ws>
Date: Fri, 05 Aug 2011 16:08:50 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <1312372647-6329-1-git-send-email-alevy@redhat.com>	<4E3C1F76.30107@codemonkey.ws>
	<CAAu8pHsE2gAq0BAXkEbQ5jtAcMRo6=0rWXU4KLjUS9hxK=d2Ug@mail.gmail.com>
In-Reply-To: <CAAu8pHsE2gAq0BAXkEbQ5jtAcMRo6=0rWXU4KLjUS9hxK=d2Ug@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] monitor: HMP: fix consecutive integer
 expression parsing
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Alon Levy <alevy@redhat.com>, qemu-devel@nongnu.org

On 08/05/2011 03:39 PM, Blue Swirl wrote:
> On Fri, Aug 5, 2011 at 4:51 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> On 08/03/2011 06:57 AM, Alon Levy wrote:
>>>
>>> Currently a command that takes two consecutive integer operations, like
>>> client_migrate_info, will be incorrectly parsed by the human monitor if
>>> the second expression begins with a minus ('-') or plus ('+') sign:
>>>
>>> client_migrate_info<protocol>    <hostname>    <port>    <tls-port>
>>> client_migrate_info spice localhost 5900 -1
>>> =>    port = 5899 = 5900 - 1
>>>     tls-port = -1
>>> But expected by the user to be:
>>>     port = 5900
>>>     tls-port = -1
>>>
>>> The fix is that for any required integer (ilM) expression followed by
>>> another
>>> integer expression (ilM) the first expression will be parsed by expr_unary
>>> instead of expr_sum. So you can still use arithmetic, but you have to
>>> enclose
>>> it in parenthesis:
>>>
>>> Command line | Old parsed result | With patch result
>>> (1+1) 2      | 2, 2              | 2, 2
>>> 1 -1         | 0, -1             | 1, -1
>>> The rest are bizarre but not any worse then before
>>> 1+2+3        | 6, 5              | 1, 5
>>> (1+2)+3      | 3, 3              | 3, 3
>>
>> I vote for just removing the expression parsing entirely.  It's incredibly
>> non-intuitive and I don't think anyone really uses it.
>>
>> Does anyone strongly object?
>
> I think the expressions would be useful with memory addresses, like
> "xp/i $pc-4", but I usually start GDB in these cases. Can we disable
> the expressions only for ports?

Not sure what you mean by ports.  You mean for anything but vc?  My goal 
in disabling the expressions would be to simplify the parsing by 
removing all that messy code.

Regards,

Anthony Liguori

>