Liste des Groupes | Revenir à c arch |
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:>
>What about bit-fields in a struct? I believe they are usuallyIn 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.
>
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.
Les messages affichés proviennent d'usenet.