https://sourceware.org/bugzilla/show_bug.cgi?id=32073
Jan Beulich <jbeulich at suse dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
Status|NEW |ASSIGNED
--- Comment #2 from Jan Beulich <jbeulich at suse dot com> ---
While this use of macros may be in widespread use, that doesn't make it correct
(and the gas/NEWS entry actually mentions a macro invocation of this same
form). Macro arguments (and parameters) don't require commas as separators.
Hence without relying on the internal workings of the gas scrubber, one can't
assume that the provided example passes a single argument; instead (following
admittedly not great documentation) it's rather 3 arguments which are being
passed. Just that gas didn't handle this correctly in the past. Let me give a
slightly more complex example:
m 101 + (1) (15) (a)
How many arguments?
The change in question had been pending comments for a long time. Sadly, as is
happening more often than not, comments actually surface only once a change was
committed and suddenly issues with (broken) existing code show up.
Parenthesizing or quoting the argument(s) helps. In case of macros with a
single argument, using :vararg in the macro definition is also a way to
approach things. At least transitionally we could also invent a mode where
macro invocations with some comma separation assumes all arguments are comma
separated, thus continuing to ignore whitespace elsewhere. That'll help
everywhere, though.
For macros with a single argument we could further effectively guess that
:vararg is in effect, yet of course that's likely to break some test in the gas
testsuite (at least I hope we have such a test there). Which of course in turn
could be worked around by adding a new "using new gas behavior" command line
option.
--
You are receiving this mail because:
You are on the CC list for the bug.
