RE: [sv-bc] white space at the end of macro text

>From: "Bresticker, Shalom" <shalom.bresticker@intel.com>

>Let me summarize my understanding, including some things which you did
>not write explicitly.
>
>Rule 1. If a string literal occurs within a text macro definition, then
>macro expansion does not occur inside it.

Yes.


>Rule 2. You can have quotation marks in a text macro definition without
>using \", but then Rule 1 applies, and macro expansion will not occur
>after an opening quotation mark until a closing quotation mark occurs.

I assume you meant `" here, instead of \".

This appears to be a re-stating of Rule 1.  String literals and text in
quotation marks are the same thing.  Is there something additional
that you were trying to say with Rule 2?


>Rule 3. You can use \" instead of " to get a quotation mark in the text
>macro definition, but then Rule 1 does not apply, and then macro
>expansion WILL occur if a macro call or a formal argument name is
>encountered.

Yes.  The `" (not \") is a sort of "delayed quote".  You do expansion
as if it were not a quote, but then at the end you turn it into a quote
and everything that is now inside quotes is considered a string literal.
As Greg said, you have to re-tokenize the macro text after the expansion.
Things that were identifiers may have become part of a string literal
(due to `") or part of a larger identifier (due to ``).

> (What happens if " is followed by \" or the reverse?)

If " is followed by `", then the `" would just be two characters in a
string literal.

For `" followed by ", I don't know.  I would guess that this is an
error.  I don't think that you can use a `" to start a string literal
and " to end that string literal.  During the first phase of expansion,
that would involve unmatched quotes.  I don't think you can have a pair
of '" delayed quotes with a string literal inside it.  That could be
interpreted as producing literal quote characters inside the string
literal, but there are problems with that idea.  The `\`" sequence
seems to be designed to produce that, implying that you can't just use
simple quotes for that effect.  And interpreting quotes as delimiting
a string literal during expansion and then changing that interpretation
to mean literal quote characters after expansion seems undesirable.

Something similar came up recently with a user, but involving a macro
argument.  As an example:

`define foo(a) `"New a Mets`"

`foo("York")

After expansion, this results in `" followed by ", which is what you
were asking about.  In this example, you could just omit the quotes
around York.  Apparently in the original example, the argument string
included commas.  Leaving the quotes off would cause the argument to
be treated as multiple comma-separated arguments.

Apparently the desired behavior was for the quotes to be dropped when
they appeared inside the delayed quotes, but there is nothing in the
LRM to support this behavior.  The desired behavior can be obtained by
using a concatenation in the macro definition, instead of relying on
the `" functionality:

`define foo(a) {"New ", a, " Mets"}

`foo("York")


>If those are the rules, I have no problem, but 1800 does not state the
>in an understandable way. Even Brad was fooled.

I don't disagree.  I was helped by knowing the macro extensions added
to the ANSI C standard to provide similar functionality.

>By the way, how can I get `` in a macro expansion?

I don't know that you can.  The LRM did not provide a general escape
rule using \ that would have allowed \`\` for this.

It doesn't seem like a big hole, since `` is not legal Verilog syntax
except inside a string literal.  And inside a normal string literal, you
just use ``.  So the only hole is if you want to create a string literal
using delayed quotes and you want it to contain ``.

>Finally, all the examples show use of the special escape sequences in
>the macro text definition. Is it possible to use them in macro actual
>arguments?

I don't think so.  The LRM only says they can be used in macro text.

Allowing them in macro actuals could be rather dangerous.  A macro
should be designed to work a certain way, and having that change
drastically based on the effects of strange arguments is probably not
a good idea.  

For example, having a chunk of the macro text turn into a string
literal because someone passed in '" as part of an argument is not
likely to be desirable.  If you intended that part of the macro
text to become a string literal, then you would have had '" in the
macro text.  And I don't think there is any reasonable way to even
pass in '' in a macro argument.  If the argument is adjacent to more
characters, so that it would get pasted onto them to make one token,
then the argument won't be recognized and substituted, because it will
already be part of a larger identifier.  The '' has to be present in
the macro text to separate the argument from the adjacent characters
so it can be recognized.

You might want to be able to pass in `\`" to get a \" into a string
being built with `".  But I'm not clear why \" can't be used, or
why `\`" was needed in the first place.


Steven Sharp
sharp@cadence.com