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.