From: "Drew B." <subs@mu-ori.me>
To: David Laight <David.Laight@aculab.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Misbehavior with setsockopt timeval structure with -fpack-struct enabled
Date: Wed, 19 Jul 2023 14:42:15 +0000 [thread overview]
Message-ID: <c8f4da177546339dfd935ed4f7441a6a@mu-ori.me> (raw)
In-Reply-To: <4ae99731d4b54c1d98f6b77f6e67d295@AcuMS.aculab.com>
Hi David!
>> #pragma pack(1, push)
>> ...
>> #pragma pack(pop)
> That is M$ C :-)
> For gcc you can use __attribute__((packed))
Noted. I new about things like __attribute__ ((unused)), but forgot
about mentioned above. My thanks!
> You also pretty much never, ever, want to 'pack' a structure
> unless you need to match a 'hardware/protocol structure' that
> has fields that aren't on their natural boundaries.
Straight to the point! That was the reason why I "packed" the things :).
> Everything that uses a structure has to use the same alignment.
> So 'randomly' packing system structures will break things.
And by 'randomly' you mean using the gcc param instead of attribute 'in
place'?
> If you need to make structures portable between architectures
> then add explicit padding to ensure 64bit items are on their
> natural boundaries (as well as byteswapping as necessary).
Frankly speaking, the size of the data is relatively small. And
byteswapping thing is resolved through the union and byte array, so
everything is being sent as a bytearray of known size and then the type
casting thing happens based on the header information.
Kind regards,
Drew.
prev parent reply other threads:[~2023-07-19 14:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 11:03 Drew B.
[not found] ` <8049a5598fe54002851b2224ada58209@AcuMS.aculab.com>
2023-07-19 14:14 ` Drew B.
[not found] ` <4ae99731d4b54c1d98f6b77f6e67d295@AcuMS.aculab.com>
2023-07-19 14:42 ` Drew B. [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c8f4da177546339dfd935ed4f7441a6a@mu-ori.me \
--to=subs@mu-ori.me \
--cc=David.Laight@aculab.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®