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

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.