Date: Wed, 29 May 2002 22:21:25 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Tony Finch <dot@dotat.at>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys gpt.h Message-ID: <12031.1022703685@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 29 May 2002 13:19:27 PDT." <20020529131927.C64995@kayak.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020529131927.C64995@kayak.xcllnt.net>, Marcel Moolenaar writes:
>On Wed, May 29, 2002 at 05:36:21PM +0100, Tony Finch wrote:
>> On Tue, May 28, 2002 at 10:36:53PM -0700, Marcel Moolenaar wrote:
>> >
>> > I see what you mean, but packing and unpacking is not the problem. It's
>> > sizeof() that's got it wrong. I don't quite understand why sizeof()
>> > would yield a size that's 4 bytes longer than the structure actually
>> > is. It smells like a gcc bug, but I assume for now I'm just missing
>> > something.
>>
>> It's required for correct alignment of the uint64_t members when you
>> create an array of the struct.
>
>I think it's a mistake to make the padding between elements in an
>array part of the type of element. An int32_t followed by an int64_t
>in a struct also doesn't cause the int32_t to have a 64-bit size
>to handle the alignment of the int64_t that follows it. It's now
>totally impossible to answer trivial questions like:
>
> what's the size of struct X { int64_t a; int32_t b; };
Welcome to "modern C" :-(
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12031.1022703685>