https://sourceware.org/bugzilla/show_bug.cgi?id=32391
--- Comment #3 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Regis Duchesne from comment #2)
Hi Régis
>> I think that this is more of a lack-of-documentation issue than a bug. >
> I respectfully disagree, I'll attempt below to argument in favor of my point
> of view.
OK.
> 2) But I claim that \@ is special, and should be treated differently.
>
> \@ is special because it is not an explicit argument. It is _implicitly_
> created by each macro, when the macro starts executing, and given its value
> at that moment in time.
And to be clear, I assume that you also feel the same about \+, correct ?
> \@ is also special because its _sole purpose_ (i.e. the reason it exists) is
> to create unique names.
Agreed. But ... it is important that not only can unique names be created, but
they can also be referenced.
> If in my entire code base, I decide that by
> convention all the labels defined in my macros will start with "_m\@_", then
> I should be guaranteed that these labels never collide. But currently that
> is not what is happening (and that is why I claim the current behavior is
> problematic):
But only if you use nested macros.
(Which does make me wonder why we support nested macros at all. Things would
be a lot simpler if we did not).
> and that is completely unexpected: I just re-organized my code, but now it
> does not assemble anymore! It goes against the principle of least surprise.
Well, I would argue that a) when you rearrange things you should be prepared to
encounter a few problems, b) if it is already working then why change anything
and c) we have not made any guarantees to adhere to the principle of least
surprise.
But still, I take your point, the behaviour is unexpected.
However - I believe that my point also stands: How does a nested macro refer to
a symbol defined in an outer macro that makes use of \@ ? Although reading on,
you have actually answered that question:
> .macro outer
> before_inner_\@:
> .macro inner label
> inside_inner_\@:
> .word \label
> .end
> inner before_inner_\@
> inner before_inner_\@
> .endm
> outer
So passing the generated label name as a macro argument solves the problem and
also works if the inner macro is not nested but defined elsewhere. Fair
enough.
But my other objection is that if we do change the behaviour of \@ we may break
already existing assembler code out there in user land that relies upon how
things currently work. Which would be bad. So we either need to implement a
new, nesting safe macro counter (eg \!) or else add a command line option to
control the behaviour of \@.
> Now I'm in a bind: how should I name the label in my inner macro to
> guarantee no collision? I could certainly adopt another label naming
> convention for all my nested macros, but what if I don't know upfront
> whether a macro will be nested or not?
Can you not include the name of the macro in the label ?
eg:
.macro outer
_outer_\@_:
nop
.macro inner
_inner_\@_:
.endm
inner
.endm
outer
This will work regardless of whether "inner" is nested or not.
> 4) Sad behavior of explicit nested arguments
>
> To further make a point about what I wrote above "\@ is special because it
> is not an explicit argument. It is _implicitly_ created by each macro, when
> the macro starts executing", I wanted to show what would happen with an
> explicitly named argument (with the same name) for both the outer and the
> inner macro. So I tried this:
>
> .macro outer arg
> outer_\arg:
> nop
> .macro inner arg
> inner_\arg:
> nop
> .endm
> inner bar
> .endm
> outer foo
>
> and I was extremely sad to discover that the output was
>
> outer_foo:
> nop
> inner_foo:
> nop
>
> i.e. the value of the outer argument is given precedence over the value of
> the inner argument! That seems completely _insane_ to me, and contrary to
> how all languages handle local variables.
Well darn. Yes, I would agree that this is wrong. (And another argument in
favour of not supporting nested macros at all. Are they really needed ?)
[Answer: Yes they are - as your talk of cpp generated code shows].
Time to dig into the internals of the macro processor I guess. :-(
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
