https://sourceware.org/bugzilla/show_bug.cgi?id=30193
Pekka Seppänen <pexu at sourceware dot mail.kapsi.fi> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Pekka Seppänen <pexu at sourceware dot mail.kapsi.fi> ---
(In reply to Nick Clifton from comment #1)
> (In reply to Pekka Seppänen from comment #0)
> Hi Pekka,
>
> > of the input string (that has been processed). As the checking currently
> > uses `len >= size' it is not possible to output a string that is exactly the
> > allocated size, e.g. `ASCII (5) "ascii"'.
>
> This is deliberate. The ASCII directive always produces a zero-terminated
> string. From the documentation:
>
> If the string is too long, a warning is issued
> and the string is truncated. The string will
> still be zero-terminated in this case.
>
I see, my bad, I was perhaps thinking this being more equal to assembler .ascii
and .asciz. Of these two only the latter produces zero-terminated string. It
would have been nice to replace 64-bit hex values (that translate to
non-terminated ascii strings) with ASCII (8) "<value>" where the value is
exactly 8 bytes.
>
> > Also, as lang_add_string() processes both ASCIZ and ASCII commands it is not
> > possible to produce an empty output, e.g. `ASCII (0) ""'. This might be
> > useful if the command would be used to produce variable padding.
>
> I find that very unlikely. Why would the padding need to be in the form of
> ascii characters ?
>
This is obviously personal preference, but I usually like to leave my handmark,
or subtle signature, on the software I'm working on. So, many times, I might
use something that is human readable as padding (or marker, for that matter).
Anyway, I see this sparked an improvement nonetheless and I learned about
testsuite internals, so I don't consider this a wasted effort.
Thanks,
-- Pekka
--
You are receiving this mail because:
You are on the CC list for the bug.
