From: Ulf Samuelsson <binutils@emagii.com>
To: Jan Beulich <jbeulich@suse.com>, Ulf Samuelsson <ulf@emagii.com>
Cc: Binutils <binutils@sourceware.org>, Nick Clifton <nickc@redhat.com>
Subject: Re: [PATCH v1 4/7] ld.texi: Add ASCII to info file
Date: Mon, 8 Jul 2024 12:57:54 +0200 [thread overview]
Message-ID: <3b34f49d-9272-72a2-6d50-3f37c8866b67@emagii.com> (raw)
In-Reply-To: <3c0bf5f6-7756-4e9f-b9ab-b24b2f86771c@suse.com>
[-- Attachment #1: Type: text/plain, Size: 3154 bytes --]
Den 2024-07-08 kl. 08:18, skrev Jan Beulich:
> On 05.07.2024 17:38, Ulf Samuelsson wrote:
>> Den 2024-07-02 kl. 10:12, skrev Jan Beulich:
>>> First: Please don't drop the mailing list from Cc. Second: Please don't
>>> top-post.
>>>
>>> On 02.07.2024 00:21, Ulf Samuelsson wrote:
>>>> I submitted the code in this patch series more than a year ago, and it got accepted.
>>>> Then a lot was reverted since I had not assigned the copyright to FSF.
>>>> For unknown reasons, my ASCIZ patches remained, but the ASCII stuff was reverted.
>>>> The reason for the naming is to be similar to how I remember naming in some assemblers where ASCIZ is zero terminated and ASCII is not zero terminated.
>>>>
>>>> If the string is too long, so it does not fit, it is really an error.
>>>> Adding a zero when truncating is a little less intrusive and may reduce runtime errors.
>>>> ASCII tells people what it is meant to be doing. ASCIIZ will make a lot of people wonder what the difference is between ASCIZ and ASCIIZ. It will also be misleading, because it does not add a zero if the string fits.
>>> Then did I read the code wrong? I was left with the impression that you'll
>>> truncate at size-1, to ensure zero termination. Plus as you say in this
>>> doc, size being 0 results in ASCIZ behavior, i.e. zero-terminates too.
>> " 111111"
>> "0123456789012345"
>>
>> ASCII (16) "This is a string"
>>
>> results in 'size' == 16. Since the string is 16 characters, 'len'
>> will be 16 as well.
> And hence
>
> else if (len >= size)
> {
> len = size - 1;
>
> would reduce len down to 15 afaics, such that ...
>
Given *ASCII 16, "This is 16 bytes*" size == 16 and strlen("This is 16
bytes") == 16,
the linker should add a 16 byte area without a terminating NUL,
If the string is shorter, then the linker should pad with NUL.
If the string is longer, then the linker should truncate the string
adding a NUL
at the end, still fitting in the area. A warning should be issued.
You could issue an error, but a warning is less intrusive.
Checked again and it needs to be changed from
else if (len >= size)
to
else if (len > size)
then the logic hopefully works out.
>> This loop will be run 16 times, and i will be 16 at the exit of
>>
>> for (i = 0; i < len; i++)
>> lang_add_data (BYTE, exp_intop (string[i]));
>>
>> Since i == 16, and size == 16, the following loop will not be run
>> even once.
>>
>> while (i++ < size)
>> lang_add_data (BYTE, exp_intop ('\0'));
>>
>> so no '\0' will be added.
> ... a '\0' will be added here? Otherwise, if I continue to overlook
> something, what I can say is that ...
>
>> ===============================
>>
>> ASCII (16) "This is a string."
>>
>> size = 16, len = 17. len > size, solen is set to 16-1 = 15.
>>
>> copy the first 15 characters in the first loop, add a single '\0' in
>> the second loop.
> ... this would be pretty odd to me: Why would a nul be inserted in
> this case, but not in the one further up?
>
> Jan
--
Best Regards
Ulf Samuelsson
next prev parent reply other threads:[~2024-07-08 10:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 21:46 [PATCH v1 0/7] ASCII output section command binutils
2024-06-28 21:46 ` [PATCH v1 1/7] ldlex.l: Add ASCII token binutils
2024-06-28 21:46 ` [PATCH v1 2/7] ldgram.y: Add ASCII parsing binutils
2024-06-28 21:46 ` [PATCH v1 3/7] ldlang.*: process ASCII command binutils
2024-07-01 6:35 ` Jan Beulich
2024-06-28 21:46 ` [PATCH v1 4/7] ld.texi: Add ASCII to info file binutils
2024-07-01 6:50 ` Jan Beulich
[not found] ` <6FDD8EBD-2371-40DB-B25B-052278BCBF49@emagii.com>
2024-07-02 8:12 ` Jan Beulich
2024-07-05 15:38 ` Ulf Samuelsson
2024-07-08 6:18 ` Jan Beulich
2024-07-08 10:57 ` Ulf Samuelsson [this message]
2024-07-08 11:07 ` Jan Beulich
2024-07-08 11:19 ` Ulf Samuelsson
2024-07-08 11:18 ` Andreas Schwab
2024-07-08 11:29 ` Ulf Samuelsson
2024-07-08 11:40 ` Jan Beulich
2024-07-08 12:10 ` Ulf Samuelsson
2024-07-08 11:48 ` Andreas Schwab
2024-07-08 12:01 ` Ulf Samuelsson
2024-07-08 12:16 ` Andreas Schwab
2024-07-08 12:22 ` Ulf Samuelsson
2024-06-28 21:46 ` [PATCH v1 5/7] Add testsuite for ASCII command binutils
2024-06-28 21:46 ` [PATCH v1 6/7] NEWS: Add " binutils
2024-06-28 21:46 ` [PATCH v1 7/7] ChangeLog: " binutils
2024-07-01 6:38 ` Jan Beulich
[not found] ` <094CF629-FDF8-436D-8B5B-62D35C3EA396@emagii.com>
2024-07-02 8:37 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3b34f49d-9272-72a2-6d50-3f37c8866b67@emagii.com \
--to=binutils@emagii.com \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.com \
--cc=nickc@redhat.com \
--cc=ulf@emagii.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).