From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3985 invoked by alias); 8 Dec 2006 18:43:28 -0000 Received: (qmail 3976 invoked by uid 22791); 8 Dec 2006 18:43:27 -0000 X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 08 Dec 2006 18:43:20 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 08 Dec 2006 10:43:19 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by orsmga001.jf.intel.com with ESMTP; 08 Dec 2006 10:43:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,515,1157353200"; d="scan'208"; a="172239822:sNHT19447589" Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 10:43:17 -0800 Received: from scsmsx413.amr.corp.intel.com ([10.3.90.32]) by scsmsx411.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 10:43:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Order "begin" probes are run Date: Fri, 08 Dec 2006 19:54:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Order "begin" probes are run Thread-Index: AccadTi8Cwr7+eq8SsCMw4B80erZZgAf10MQ From: "Stone, Joshua I" To: "Frank Ch. Eigler" Cc: X-OriginalArrivalTime: 08 Dec 2006 18:43:17.0805 (UTC) FILETIME=[B9FEE5D0:01C71AF8] X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00642.txt.bz2 On Thursday, December 07, 2006 7:02 PM, Frank Ch. Eigler wrote: > The change to unary number parsing is probably suspect though, in that > it introduces parsing errors or ambiguities. I thought we had a test > for some instances of this problem. There's definitely a token abiguity, as already noted in the lexer comments -- should "1-1" be '1'+'-'+'1' or '1'+'-1'? That's why I didn't make the change in the lexer. > If there is any doubt, I would suggest rolling this back, and let the > probe point parser accept an explicit negation operator as an optional > prefix. Well, I implemented the check for negative in parse_literal, which is near the bottom of the parsing stack. There are three contexts where this is called: global initialization and probe point parameters, where binary operators aren't allowed; and parse_value, where both binary and unary operators have already been accounted for. If you can think of a test case where this fails, please let me know. We now get the bonus that global numeric initializers can be negative as well. However, I just noticed a bug, or at least surprise behavior, in the way globals are initialized: global a =3D 42 probe begin(-1), begin(1) { printf("%d ", ++a) This will print "1 43 ". It's not really a problem with the sequencing, but it's because "global a=3D42" gets synthesized to "global a probe begin{a=3D42}" -- so the order that the initialization happens is generally undefined. Even changing it to begin(-2^63) isn't really correct, as it should happen *before* the beginning. I will file a bug and investigate this. There's a comment indicating that a C-initializer might be the way to go, so I'll probably go that route. Josh