RE: [sv-bc] 1339: (RESEND)`define behavior on trimming leading and trailing spaces in macros

I have occasionally looked at macro-expanded text, for example, in order
to understand what was the final code used by the compiler.

Both conventions are inconsistent with the general way in which
backslashed characters are treated in string literals. See Mantis 1507.

I agree with this interpretation:
> Basically if we have a 
> multi-line string literal embedded inside of a multi-line 
> macro, the escape character along with the newline are 
> stripped.  The construction of the string literal now has no 
> issues if it's across a multi-line macro.

The point of 1397 is to say that the backlash-newline continues both the
string and the macro. As you say, it should be considered stripped-out.

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Alsop, Thomas R
> Sent: Wednesday, November 21, 2007 3:54 PM
> To: Greg Jaxon
> Cc: sv-bc@server.eda.org
> Subject: RE: [sv-bc] 1339: (RESEND)`define behavior on 
> trimming leading and trailing spaces in macros
> 
> Honestly I just can't think of any macro expanded text that I 
> have ever "looked at". So I'll stand out on a limb and say 
> that I really don't care if we remove the newline too if that 
> makes implementation easier and reduces the divergence of 
> these conventions. 
> 
> I think this would help resolve Mantis 1397 too (which is 
> where I think you were heading:)  Basically if we have a 
> multi-line string literal embedded inside of a multi-line 
> macro, the escape character along with the newline are 
> stripped.  The construction of the string literal now has no 
> issues if it's across a multi-line macro.
> 
> Should we move ahead with a proposal to this effect for 1397?
> 
> -Tom 
> 
>  
> 
> >-----Original Message-----
> >From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
> >Sent: Tuesday, November 20, 2007 9:54 PM
> >To: Alsop, Thomas R
> >Cc: sv-bc@eda.org
> >Subject: Re: [sv-bc] 1339: (RESEND)`define behavior on 
> trimming leading
> and
> >trailing spaces in macros
> >
> >The `" feature can turn just about any macro expansion text 
> into string 
> >data, where it becomes a matter of program portability.
> >
> >If these two conventions were in agreement, I wouldn't 
> personally care 
> >which way it was done.  Having them disagree seems to require more 
> >explanation.
> >
> >Alsop, Thomas R wrote:
> >> The only reason I can think of would be readability of the 
> expanded 
> >> macro text.  That's it.  But I am still grappling with 
> whether or not 
> >> there is a reason to be able to read this code.  If we 
> pull out the 
> >> newlines then our expanded macro is all on one line. 
> That's fine for 
> >> machine consumption, not human. Are there any tools that 
> you know of 
> >> that force us designers to look at the replaced text?
> >>
> >> Thanks,
> >> -Tom
> >>
> >>> -----Original Message-----
> >>> From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
> >>> Sent: Tuesday, November 20, 2007 2:39 PM
> >>> To: Alsop, Thomas R
> >>> Cc: sv-bc@eda.org
> >>> Subject: Re: [sv-bc] 1339: (RESEND)`define behavior on trimming
> leading
> >> and
> >>> trailing spaces in macros
> >>>
> >>> Section 3.6 String Literals gives a different semantics for the
> >> backslash-
> >>> newline ligature:
> >>>
> >>>> A string literal must be contained in a single line 
> unless the new 
> >>>> line is immediately preceded by a \ (back slash).
> >>>> In this case, the back slash and the new line are ignored.
> >>> Note that it does not inject a newline into the string data - \n 
> >>> does that job, leading to the idiom "... \n\ "
> >>>
> >>> Is there any good reason to inject this newline into macro
> replacement
> >>> text?
> >>>
> >>> I need more time and experiments to reply to your other points,
> Thomas.
> >>>
> >>> Later,
> >>> Greg
> 
> --
> 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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.