mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

      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®