Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #103433

Re: Preprocessor expressions

Show all headers | View raw

On 07/02/17 23:09, BartC wrote:
> On 07/02/2017 21:16, supercat@casperkitty.com wrote:
>> On Tuesday, February 7, 2017 at 3:01:36 PM UTC-6, Bart wrote:
>>> My experience at the moment (translating from a non-C language to C, in
>>> a recent working project) is that things such as pointer sizes, and
>>> struct-member offsets, will be fixed. That means that generated C
>>> requires things like pack(1), and to be compiled for a particular
>>> pointer size.
>>
>> I would think it should be fairly straightforward to keep track of the
>> required alignment for each type, and insert padding bytes in structure
>> definitions as needed to maintain alignment.  While the Standard allows
>> implementations to use arbitrary padding rules, the vast majority use
>> a simple rule which says that every object will be preceded by whatever
>> amount of padding would be needed to reach the next multiple of its
>> alignment, and every structure or union will have the same alignment
>> requirement as its coarsest member.  If your code knows the required
>> alignment for each primitive, it should be able to add byte fields with
>> dummy names so as to ensure that a compiler would never need to add any
>> padding of its own unless it uses very weird structure layout rules.
>>
> 
> I had once a project which had a struct with this layout:
> 
>   struct {
>       int a;                // 32 bits
>       double b;             // 64 bits
>       int c;                // 32 bits
> }
> 
> (The real thing was a lot more complex with anonymous unions everywhere.
> But it had carefully crafted to occupy 16 bytes in total.)
> 
> On x86-32, the compiler was quite happy to put member 'b' at offset 4.
> 
> But when I compiled it for 32-bit ARM, the same compiler, gcc, had to
> put 'b' at offset 8, which made the struct an odd size like 20 bytes.

It will be 24 bytes, with padding at the end too.

> 
> This is why I think you can't always predict what a compiler will do.

Perhaps /you/ can't predict what the compiler will do - but people who
know their compilers can.  The alignment of types is implementation
dependent - it can vary between compilers (even on the same platform),
but will be consistent and predictable for any given implementation.

As Supercat says, the easiest method is to assume that alignment matches
size - then your structs will never be bigger than you expect.
Alignment of a type can never be bigger than the type's size (counting
any internal padding bits in the type as part of its size).

If you want to avoid structs being smaller than you expect, add padding
explicitly.

So with

   struct X {
       double b;             // 64 bits
       int a;                // 32 bits
       int c;                // 32 bits
 };

You will always get 16 byte structs with 8 byte alignment (assuming
CHAR_BIT == 8).  If you really want the order a, b, c and you want to be
sure of the layout on all systems (with the same size of int and
double), use:

   struct Y {
       int a;                // 32 bits
       int padding1;
       double b;             // 64 bits
       int c;                // 32 bits
       int padding2;
 }

If you are using gcc, then you can use "-Wpadded" to give you a warning
if the compiler has inserted struct padding itself.

It is also a good idea to check your structs - static_assert() is your
key tool here:

	static_assert(sizeof(struct X) == 16);
	static_assert(sizeof(struct Y) == 24);

offsetof can also come in handy when checking large struct layouts.


(This is something I have to do regularly, for structs that match
hardware register layouts, data communicated between devices, or data
stored in non-volatile memory.)

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Preprocessor expressions BartC <bc@freeuk.com> - 2017-01-22 13:24 +0000
  Re: Preprocessor expressions jameskuyper@verizon.net - 2017-01-22 07:52 -0800
    Re: Preprocessor expressions Ralf Damaschke <rwspam@gmx.de> - 2017-01-22 17:15 +0000
      Re: Preprocessor expressions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-22 13:32 -0500
    Re: Preprocessor expressions BartC <bc@freeuk.com> - 2017-01-22 17:38 +0000
      Re: Preprocessor expressions Thiago Adams <thiago.adams@gmail.com> - 2017-02-01 03:12 -0800
        Re: Preprocessor expressions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-01 11:44 +0000
        Re: Preprocessor expressions BartC <bc@freeuk.com> - 2017-02-01 11:56 +0000
        Re: Preprocessor expressions jameskuyper@verizon.net - 2017-02-01 08:35 -0800
          Re: Preprocessor expressions Thiago Adams <thiago.adams@gmail.com> - 2017-02-02 09:23 -0800
            Re: Preprocessor expressions BartC <bc@freeuk.com> - 2017-02-02 18:14 +0000
              Re: Preprocessor expressions Keith Thompson <kst-u@mib.org> - 2017-02-02 10:35 -0800
              Re: Preprocessor expressions Thiago Adams <thiago.adams@gmail.com> - 2017-02-02 17:09 -0800
                Re: Preprocessor expressions Thiago Adams <thiago.adams@gmail.com> - 2017-02-05 10:09 -0800
                Re: Preprocessor expressions Thiago Adams <thiago.adams@gmail.com> - 2017-02-05 10:38 -0800
                Re: Preprocessor expressions Thiago Adams <thiago.adams@gmail.com> - 2017-02-05 11:03 -0800
                Re: Preprocessor expressions BartC <bc@freeuk.com> - 2017-02-06 15:17 +0000
                Re: Preprocessor expressions Thiago Adams <thiago.adams@gmail.com> - 2017-02-07 05:36 -0800
                Re: Preprocessor expressions BartC <bc@freeuk.com> - 2017-02-07 21:01 +0000
                Re: Preprocessor expressions supercat@casperkitty.com - 2017-02-07 13:16 -0800
                Re: Preprocessor expressions BartC <bc@freeuk.com> - 2017-02-07 22:09 +0000
                Re: Preprocessor expressions supercat@casperkitty.com - 2017-02-07 14:33 -0800
                Re: Preprocessor expressions Keith Thompson <kst-u@mib.org> - 2017-02-07 14:52 -0800
                Re: Preprocessor expressions BartC <bc@freeuk.com> - 2017-02-08 00:13 +0000
                Re: Preprocessor expressions Keith Thompson <kst-u@mib.org> - 2017-02-07 16:39 -0800
                Re: Preprocessor expressions jameskuyper@verizon.net - 2017-02-07 16:47 -0800
                Re: Preprocessor expressions David Brown <david.brown@hesbynett.no> - 2017-02-08 10:03 +0100
                Re: Preprocessor expressions Keith Thompson <kst-u@mib.org> - 2017-02-08 09:19 -0800
                Re: Preprocessor expressions Thiago Adams <thiago.adams@gmail.com> - 2017-02-08 12:35 -0800
                Re: Preprocessor expressions Thiago Adams <thiago.adams@gmail.com> - 2017-02-09 05:25 -0800
                Re: Preprocessor expressions supercat@casperkitty.com - 2017-02-09 07:37 -0800
                Re: Preprocessor expressions BartC <bc@freeuk.com> - 2017-02-09 15:52 +0000
  Re: Preprocessor expressions BartC <bc@freeuk.com> - 2017-01-22 19:34 +0000
    Re: Preprocessor expressions jameskuyper@verizon.net - 2017-01-22 13:01 -0800
  Re: Preprocessor expressions Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:30 -0800

csiph-web