This is the mail archive of the
mailing list for the binutils project.
Re: .asciz - implementation or documentation wrong?
>>> On 06.07.11 at 10:21, Erik Christiansen <email@example.com> wrote:
> On 05.07.11 12:38, Jan Beulich wrote:
>> Documentation as well as the comment prior to stringer() say that the
>> directive (like .ascii, but there it doesn't matter that much) expects
>> comma separated double quoted strings. Yet a missing comma between
>> two strings is taken as if there was one (whereas simply concatenating
>> such strings - without any NUL character in between - would seem like
>> the much better alternative).
> Jan, in comparison, I'm having trouble seeing any documentation vs
> behaviour difference, on a quick check with:
> $ avr-as --version
> GNU assembler (GNU Binutils) 2.20
> Here, input of:
> .asciz "AAAA", "BBBB"
> .asciz "CCCC" "DDDD"
This line ought to be rejected according to the documentation.
> .ascii "EEEE", "FFFF"
> .ascii "GGGG" "HHHH"
As should this one.
> 8 .data
> 9 0000 4141 4141 .asciz "AAAA", "BBBB"
> 9 0042 4242
> 9 4200
> 10 000a 4343 4343 .asciz "CCCC" "DDDD"
> 10 0044 4444
> 10 4400
That's precisely what I'm seeing.
> 11 0014 4545 4545 .ascii "EEEE", "FFFF"
> 11 4646 4646
> 12 001c 4747 4747 .ascii "GGGG" "HHHH"
> 12 4848 4848
> AFAICS, ascii and asciz are both indifferent to the comma, and
> everything is concatenated as expected, with NULs where required.
> If an inconsistency exists in newer binutils, and documentation does not
> mandate it, then that is a regression, I submit.
> If the post is a proposal to implement, and document, "Only one NUL, if
> no commas", then the breaking of a few existing assembler programs may
> be the price.
I realize that, which is why I didn't send a patch right away.
> The introduction of Awk-like string concatenation syntax
> seems cute, but doesn't achieve anything that can't be done by eliding
> the two quotes and space to begin with.
Eliding the quotes may not be possible - just consider the case of
passing a .S file through a C pre-processor, and the intended string
consisting of multiple pieces, some or all of which are pre-processor
> At least then, the program is
> more honestly explicit: z means each string is zero terminated.
> "`.asciz' is just like `.ascii', but each string is followed by a zero
> So is there any gain to offset the pain of changing that?
> In a time of drastic change it is the learners who survive; the
> 'learned' find themselves fully equipped to live in a world that no
> longer exists. - Eric Hoffer