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.