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

Groups > comp.lang.c > #103425

Re: Preprocessor expressions

Show all headers | View raw

BartC <bc@freeuk.com> writes:
> On 07/02/2017 22:52, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> 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.
>>
>> A size of 20 bytes seems unlikely.  If the compiler imposes 8-byte
>> alignment on type double, then it should also impose 8-byte alignment on
>> the structure.  The structure was probably 24 bytes.
>
> So a struct of a double and an int is always going to be 16 bytes and 
> never 12? (I used a 12-byte version for a while; I guess either that 
> wasn't C, or I used pack(1).)

The alignment of any structure type is always at least the alignment of
any of its members, and the size is always a whole multiple of the
alignment.  This is necessary for array indexing to work.  (Trailing
padding might not be necessary if arrays could have gaps between
elements, but C doesn't permit that.)

>>> This is why I think you can't always predict what a compiler will do.
>>
>> 99% of the time you don't have to.  Usually you don't need to *tell* the
>> compiler how things are allocated,
>
> The context here is representing a struct whose layout has already been 
> decided so that the C version has to match it exactly. Or the struct 
> represents some layout in a file header, or a data packet from a comms 
> link or whatever.

Yes, an externally imposed format is certainly a valid reason.

> C is supposed to be low-level so why not allow that amount of control?

I'm not going to debate what C *should* do.

[...]

>> I presume you have valid reasons for wanting a particular layout.
>> (No sarcasm there, I really do presume you have valid reasons.
>> I don't particularly need to know what they are.)
>
> Again, C is not a high-level language where these details can be and 
> usually are irrelevant.
>
> For my purposes they can be very relevant. I've used variations of such 
> a 16-byte struct since the mid-80s. I usually need to pack a lot in and 
> it needs to be very carefully crafted because performance depends on 
> keeping it compact.
>
> (The latest version here: http://pastebin.com/rHqBYEqj. 26 or so fields 
> in only 16 bytes. And this new version has had to offload a lot of stuff 
> too thanks to 64-bit pointers taking up half the space.
>
> But notice no padding is actually needed; the manual layout has already 
> taken care of that.)

Right, if you can order the fields so that the most strictly aligned
members are first, you can often avoid padding.  And many C
implementations have extensions that let you specify packing (often at
the expense of slower code).

Note that gcc's packing extensions, and likely those of other languages,
can be unsafe if you're not careful.  For example, if you have a
structure like
    struct { char c; int x; };
and you use an extension to force the int member to be misaligned, then
the compiler will generate correct code if you access obj.x, but if it
let's you take the address of a misaligned member, any code that
dereference the resulting pointer can blow up.

http://stackoverflow.com/q/8568432/827263
http://stackoverflow.com/a/8568441/827263

If you really need absolute control over layout (short of using a
different language), you can alway manipulate your data using arrays of
unsigned char with memcpy().  The result is going to be extremely
tedious.  I'm not recommending it, just pointing out that the
possibility is there.

I'll also mention that most externally imposed data layouts are likely
designed to be used from C code, and will therefore tend to avoid
alignment problems.  Of course that's not much help if you happen to be
dealing with a layout that wasn't designed that way.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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