Shalom, I am a bit concerned that there hasn't been a serious attempt yet to come up with a *basis* for arguing about the space handling cases. There are important choices regarding either more text-based, token-based, or other semantically rich approaches. Any such choice will have a huge bearing on how and why we make decisions in certain cases. The simple base cases are a starting point for discussion but until we determine the overall effect, making a particular choice and encoding it right now in the LRM could in fact do more harm than good in the long run. Gord. Bresticker, Shalom wrote: > I'm all for deciding on this case, but currently the interactions are > undefined not only for this case, but for others as well, and users do > not have consistent behavior between tools. The proposal in any case > does not de-define an already defined case. > > Shalom > > ------------------------------------------------------------------------ > *From:* Coffin, Eric [mailto:eric_coffin@mentor.com] > *Sent:* Friday, October 26, 2007 12:35 AM > *To:* sv-bc@server.eda-stds.org; Brad Pierce > *Cc:* Bresticker, Shalom > *Subject:* Re: [sv-bc] Trimming whitespace from macro actuals > > Ignoring backward compatibility (for the time being) and > implementation details, which source text option is equivalent to > the expanded macro? Assume that the text "<space>" represents a > single ASCII character (character number 32). > > `define MACRO( A, B ) `"A``B`" > > `MACRO( \M<space> , \Q<space> ) > > Option 1) "\M\Q<space>" > Option 2) "\M\Q" > Option 3) "\MQ" > Option 4) "\MQ<space>" > Option 5) "\M<space>\Q<space>" > Option 6) "\MQ`" Note that this is a quote followed > by an escaped identifier \MQ`" > > Undefined interactions exist between escaped identifiers, token > pasting (gluing) and the `" macro operation. Passing something may > not be better than nothing in this case. > > -Eric > > Bresticker, Shalom wrote: >> Even if it's not perfect, let's pass something which is better than >> nothing. >> >> Shalom >> >> >>> -----Original Message----- >>> From: owner-sv-bc@server.eda.org >>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom >>> Sent: Sunday, October 21, 2007 2:11 PM >>> To: sv-bc@server.eda-stds.org >>> Subject: RE: [sv-bc] Trimming whitespace from macro actuals >>> >>> This issue, whether and how white space around macro actual >>> arguments is stripped off or preserved, was never resolved in >>> a proposal to clarify the LRM, so I have filed Mantis 2140 >>> and the attached proposal. >>> >>> Please review. >>> >>> Thanks, >>> Shalom >>> >>> --------------------------------------------------------------------- >>> Intel Israel (74) Limited >>> >>> This e-mail and any attachments may contain confidential >>> material for the sole use of the intended recipient(s). Any >>> review or distribution by others is strictly prohibited. If >>> you are not the intended recipient, please contact the sender >>> and delete all copies. >>> >>> -- >>> This message has been scanned for viruses and dangerous >>> content by MailScanner, and is believed to be clean. >>> >>> >>> >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Oct 26 07:32:58 2007
This archive was generated by hypermail 2.1.8 : Fri Oct 26 2007 - 07:33:12 PDT