[PATCH v1 4/7] ld.texi: Add ASCII to info file

[Ulf Samuelsson]

Den 2024-07-08 kl. 13:07, skrev Jan Beulich:
> 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

Because if the warning is ignored, then I expect less havoc if the code 
is running.


The typical use I see is in a header where a field has a predefined size.

The user will be responsible for manually adding a NUL byte so the
typical directive is

ASCII 16, "This is 15 byte\0"   ; 16 byte string

ASCII 16, "This is 15\0\0\0\0\0\0"   ; 16 byte string

If the user adds

ASCII 16, "This is 15 bytes\0"  ; 17 byte string

the string is too long.

As the string is truncated, there is no ending NUL character,
and if the string is printed, expecting an ending NUL character
a severe problem may occur.

-- 
Best Regards
Ulf Samuelsson