Path: ...!npeer.as286.net!npeer-ng0.as286.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.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 20:47:11 +0200
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <vc7a3f$2afrl$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> <vc73bl$28v0v$1@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 20:47:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f814bd11c9fbe5b78942ec153f06f57";
	logging-data="2441077"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/C/tKDUHtteTNS3SVBjZhbzUry4xRTRA4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ardgEu/fj30SGfk+PGE15FVmEVY=
Content-Language: en-GB
In-Reply-To: <vc73bl$28v0v$1@dont-email.me>
Bytes: 5422

On 15/09/2024 18:52, Robert Finch wrote:
> 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.
> 

Generally, they are packed if you make the fields of the same type, but 
if you change the type you get a new block that is aligned appropriately 
for the type you gave.  It is certainly the case that bit-field struct 
layout is complicated, not well-specified in the C standards, and often 
not as well documented as it could be by compilers.

When I use bit-field layouts and the layout matters (such as for an I/O 
device, rather than just to collect lots of small bits of data in less 
memory), I like to give any padding explicitly.  And I put a 
static_assert on the size of the struct, to be sure I haven't got it 
wrong.  Such code is, naturally, never intended to be very portable.