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: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sun, 15 Sep 2024 18:51:28 -0700
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <86bk0ocqn3.fsf@linuxsc.com>
References: <vaqgtl$3526$1@dont-email.me> <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> <OvEFO.70694$EEm7.38286@fx16.iad> <86wmjcd7yf.fsf@linuxsc.com> <giKFO.21564$rIH3.21263@fx40.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 16 Sep 2024 03:51:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ed2c1c22c2facd770a4416268b44112b";
	logging-data="2614098"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19cbYWZs4qBXrhf1zGYBFY7BNc0IEjiQeY="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:8e7htCA9+/sgADLG8hgdYZTeSPc=
	sha1:qWzBtZwHtPxIQKthAJZvwm675sc=
Bytes: 3366

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Robert Finch <robfi680@gmail.com> writes:
>>>
>>>> On 2024-09-15 12:09 p.m., David Brown wrote:
>>>>
>>>>>> 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.
>>>
>>> That's a bit more complicated as it depends on the target byte-order.
>>>
>>> e.g.
>>>
>>>     struct GIC_ECC_INT_STATUSR_s {
>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>>         uint64_t reserved_41_63              : 23;
>>>         uint64_t dbe                         :  9;
>>>         uint64_t reserved_9_31               : 23;
>>>         uint64_t sbe                         :  9;
>>> #else
>>>         uint64_t sbe                         :  9;
>>>         uint64_t reserved_9_31               : 23;
>>>         uint64_t dbe                         :  9;
>>>         uint64_t reserved_41_63              : 23;
>>> #endif
>>>     } s;
>>
>> Probably many people know that this code depends on an
>> implementation-defined extension (allowing uint64_t as
>> the type of a bitfield) and is not guaranteed to be
>> portable.  Using 'unsigned' instead would be portable
>> (assuming typical 32-bit ints, etc).
>
> Portability in this case was not necessary.  In any case,
> it's portable to clang and gcc, which is good enough.

I'm not criticizing the code;  just pointing out an aspect
in case some people weren't aware of it.