Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sun, 15 Sep 2024 12:52:04 -0400
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <vc73bl$28v0v$1@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>
 <vc70sl$285g2$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 15 Sep 2024 18:52:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3222acdc67edaf9445b22785b52765d7";
	logging-data="2391071"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+J4+fOAqix6xGpG7EDDXczilehaSP0jqs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:zv6OxDBILQ4ndMbIIzosbwdPPpk=
Content-Language: en-US
In-Reply-To: <vc70sl$285g2$4@dont-email.me>
Bytes: 4497

On 2024-09-15 12:09 p.m., David Brown wrote:
> 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.
>>
> 
What about bit-fields in a struct? I believe they are usually packed. In 
case its for something like an I/O device.