public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Ulf Samuelsson <binutils@emagii.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 13:07:22 +0200	[thread overview]
Message-ID: <a003ea1f-d33c-4fa7-90fb-c77e841fa7c2@suse.com> (raw)
In-Reply-To: <3b34f49d-9272-72a2-6d50-3f37c8866b67@emagii.com>

On 08.07.2024 12:57, Ulf Samuelsson wrote:
> 
> 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.

What I'm still actually missing a reason for is why in this case you
want to insert a nul while in the len == size case you want to keep
the string as is. To me this is inconsistent and hence yielding
surprising behavior. Yet with that harmonized (whichever direction)
it'll then become clear whether the directive wants to be ASCII or
ASCIZ (or alike).

Jan

  reply	other threads:[~2024-07-08 11:07 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
2024-07-08 11:07               ` Jan Beulich [this message]
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=a003ea1f-d33c-4fa7-90fb-c77e841fa7c2@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@emagii.com \
    --cc=binutils@sourceware.org \
    --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).