Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sun, 15 Sep 2024 18:09:56 +0200
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <vc70sl$285g2$4@dont-email.me>
References: <vaqgtl$3526$1@dont-email.me>
 <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com>
 <2024Sep8.173639@mips.complang.tuwien.ac.at>
 <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
 <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z>
 <2024Sep11.123824@mips.complang.tuwien.ac.at> <vbsoro$3ol1a$1@dont-email.me>
 <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com>
 <vbuu5n$9tue$1@dont-email.me> <20240915001153.000029bf@yahoo.com>
 <vc6jbk$5v9f$1@paganini.bofh.team> <20240915154038.0000016e@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 15 Sep 2024 18:09:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f814bd11c9fbe5b78942ec153f06f57";
	logging-data="2364930"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/4/dc6vUbr+V9byvG8JsL34cN+GVDRVOk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:RWeZksT20pFc3bTL25rylqdSvQ4=
Content-Language: en-GB
In-Reply-To: <20240915154038.0000016e@yahoo.com>

On 15/09/2024 14:40, Michael S wrote:
> On Sun, 15 Sep 2024 12:19:02 -0000 (UTC)
> Waldek Hebisch <antispam@fricas.org> wrote:
> 
>> Michael S <already5chosen@yahoo.com> wrote:
>>> On Thu, 12 Sep 2024 16:34:31 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>    
>>>> On 12/09/2024 13:29, Michael S wrote:
>>>>> On Thu, 12 Sep 2024 03:12:11 -0700
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>>      
>>>>>> BGB <cr88192@gmail.com> writes:
>>>>
>>>> I fully agree that C is not, and should not be seen as, a
>>>> "high-level assembly language".  But it is a language that is very
>>>> useful to "hardware-type folks", and there are a few things that
>>>> could make it easier to write more portable code if they were
>>>> standardised.  As it is, we just have to accept that some things
>>>> are not portable.
>>>>> Why not?
>>>>> I don't see practical need for all those UBs apart from buffer
>>>>> overflow. More so, I don't see the need for UB in certain limited
>>>>> classes of buffer overflows.
>>>>>
>>>>> struct {
>>>>>    char x[8]
>>>>>    int  y;
>>>>> } bar;
>>>>> bar.y = 0; bar.x[8] = 42;
>>>>>
>>>>> IMHO, here behavior should be fully defined by implementation.
>>>>> And in practice it is. Just not in theory.
>>>>>      
>>>>
>>>> And how should that be defined?
>>>
>>>
>>> bar.x[8] = 42 should be defined to be the same as
>>>    char tmp = 42
>>>    memcpy(&bar.y, &tmp, sizeof(tmp));
>>
>> That has two drawbacks: minor one that you need to know that
>> there are no padding between 'x' and 'y'.
> 
> Padding is another thing that should be Implementation Defined.

It is.

> I.e. compiler should provide complete documentation of its padding
> algorithms.

They do.  Or, they should.  Often they are lazy and say "defined by the 
platform ABI".  Really, it is only the alignments that are needed.

C defines the minimum padding between members in a struct - you get the 
padding needed to ensure that members are correctly aligned.  I don't 
think the C standards disallow additional padding, but it would be an 
extraordinarily strange implementation if there were anything more than 
this minimum padding.

But I certainly wouldn't mind if the standards dictated this minimum 
padding, and then there would be nothing left to the implementation 
other than alignments.

> In addition, some padding-related things can be defined by Standard
> itself. Not in this particular case, but, for example, it could be
> defined that when field of one integer type is immediately followed by
> another field of integer type with the same or narrower width then
> there should be no padding in-between.
>