This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: QUOTES_IN_INSN
- From: Ian Lance Taylor <ian at airs dot com>
- To: "Jan Beulich" <JBeulich at novell dot com>
- Cc: <binutils at sources dot redhat dot com>
- Date: 02 May 2005 14:49:50 -0400
- Subject: Re: QUOTES_IN_INSN
- References: <s275f1ef.010@emea1-mh.id2.novell.com>
"Jan Beulich" <JBeulich@novell.com> writes:
> Currently, only ia64 defines this. In order to facilitate passing
> strings to macros I think the code protected by this needs to be
> generally enabled, otherwise stuff like
>
> .macro m str
> .asciz "\str"
> .endm
>
> m "foo;bar"
>
> doesn't work (whereas a plain
>
> .asciz "foo;bar"
>
> does obviously work).
>
> Are there any contra-indications to such a change (i.e. are there
> targets that can't tolerate this)?
I would expect that this would work OK.
> In any case, shouldn't the code in read.c currently protected by
> this be dealing with '\n' specially (to at least increment the line
> counter)? What is the intended meaning of a quoted '\n' anyway?
> Shouldn't there rather be a warning about a missing closing quote
> (and the line be terminated there)?
I believe the MRI assembler allows you to quote a newline. It's true
that bump_line_counters should be called in that case. I don't know
about ia64.
> Additionally, as I'm seeing a number of similar issues in the macro
> handling code: Is there a formal specification somewhere about the
> expected behavior of both the assembler in general and the macro
> code in particular, so one could reasonably judge whether a certain
> construct being rejected or producing unexpected results is a bug
No.
Ian