Path: ...!2.eu.feeder.erje.net!feeder.erje.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 18:14:40 +0200
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <vc715h$285g2$5@dont-email.me>
References: <20240915154038.0000016e@yahoo.com>
 <memo.20240915154108.19028v@jgd.cix.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 15 Sep 2024 18:14:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f814bd11c9fbe5b78942ec153f06f57";
	logging-data="2364930"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18VreqNSYoYLNZ43p5H767O/YxCPAKHmQI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/cF4xROFW5FKF1hxMW3QUFV2ufI=
In-Reply-To: <memo.20240915154108.19028v@jgd.cix.co.uk>
Content-Language: en-GB
Bytes: 3394

On 15/09/2024 16:41, John Dallman wrote:
> In article <20240915154038.0000016e@yahoo.com>, already5chosen@yahoo.com
> (Michael S) wrote:
> 
>> Padding is another thing that should be Implementation Defined.
>> I.e. compiler should provide complete documentation of its padding
>> algorithms.
> 
> It is, and they do. I've used a lot of different compilers over the last
> 29 years, needing to know about padding for a DIY varargs, and I've never
> had problems with finding out what the padding was.
> 
> It can usually be described quite briefly, by saying that all data types
> are naturally aligned. The only variant of that I've encountered is on
> 32-bit x86 Linux and 32-bit POWER AIX where in both cases 8-byte doubles
> were 4-byte aligned.
> 

It is better to say types are naturally aligned up to a maximum 
appropriate for the architecture (usually the width of general-purpose 
registers and/or pointers).  Then there are far fewer exceptions.

(So on 8-bit devices you usually see single byte alignment even for 
64-bit types.)

> The C standard specifies that struct members shall be stored in memory in
> the same order as they appear in the declaration. It does not specify
> padding because the standard committee feel they need to allow C to work
> on machines that are not byte-addressed or are otherwise weird.
> 

It specifies that there can be padding between members, and members need 
to be aligned, so it gives the minimum padding (though the alignment 
requirements are implementation-defined).  But it gives no maximum 
padding, AFAIK.

>> 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.
> 
> That would be fine if you were willing to confine yourself to
> byte-addressed machines.
> 

There would not be padding between one integer type and another member 
of the same or smaller integer type, unless you have a very odd 
architecture or niche features (like, say, an int24_t with 1-byte 
alignment followed by an int16_t with 2-byte alignment).