public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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

  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).