From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25259 invoked by alias); 2 May 2005 18:50:06 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 25200 invoked from network); 2 May 2005 18:49:59 -0000 Received: from unknown (205.217.158.180) by sourceware.org with QMTP; 2 May 2005 18:49:59 -0000 Received: (qmail 6625 invoked by uid 10); 2 May 2005 18:49:59 -0000 Received: (qmail 14258 invoked by uid 500); 2 May 2005 18:49:50 -0000 Mail-Followup-To: binutils@sources.redhat.com, JBeulich@novell.com To: "Jan Beulich" Cc: Subject: Re: QUOTES_IN_INSN References: From: Ian Lance Taylor Date: Mon, 02 May 2005 18:50:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-05/txt/msg00037.txt.bz2 "Jan Beulich" 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