Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #103424
| Path | csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | BartC <bc@freeuk.com> |
| Newsgroups | comp.lang.c |
| Subject | Re: Preprocessor expressions |
| Date | Wed, 8 Feb 2017 00:13:34 +0000 |
| Organization | A noiseless patient Spider |
| Lines | 74 |
| Message-ID | <o7dno5$ei8$1@dont-email.me> (permalink) |
| References | <o62bn5$kms$1@dont-email.me> <d4b65b12-2c67-475e-9121-8d96874df453@googlegroups.com> <o62qjg$ib0$1@dont-email.me> <53636d82-e300-4745-9cf3-b4848b97d8b9@googlegroups.com> <7a6cc8a1-6241-486e-bd87-43a0ccbe78b6@googlegroups.com> <634d154c-9d22-4a83-8d3c-85ca4b89ae06@googlegroups.com> <mGKkA.214862$3L.178811@fx26.am4> <e3c53979-10e8-44e4-b6c4-0cd5b65ae78f@googlegroups.com> <4bb1dbcd-6e3c-40df-8319-eb33b8bfa685@googlegroups.com> <030e3613-d745-46c4-8a46-d625eb276baa@googlegroups.com> <o7a3u7$9u$1@dont-email.me> <1e988be1-ec21-4335-8f79-e6d1e213f1c7@googlegroups.com> <o7dcfu$69q$1@dont-email.me> <86f1f0c5-5f44-4bab-8cd2-074b407220e8@googlegroups.com> <o7dgfs$ksp$1@dont-email.me> <ln37fp1umt.fsf@kst-u.example.com> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=windows-1252; format=flowed |
| Content-Transfer-Encoding | 7bit |
| Injection-Date | Wed, 8 Feb 2017 00:11:49 -0000 (UTC) |
| Injection-Info | mx02.eternal-september.org; posting-host="04f46627e993918eed6ed1c214028ab2"; logging-data="14920"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+FPnthwkP6FrZcBxQJ7sk+" |
| User-Agent | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
| In-Reply-To | <ln37fp1umt.fsf@kst-u.example.com> |
| Cancel-Lock | sha1:TcS79cy0W2ID5nmU/tZc/mxg31I= |
| Xref | csiph.com comp.lang.c:103424 |
Show key headers only | View raw
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).)
>> 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.
C is supposed to be low-level so why not allow that amount of control?
you can just *ask* it, using sizeof,
> offsetof, and possibly _Alignof (which is new in C11).
Sure; but at the point where the decision is made (in another language
or working out some file header), the C compiler stage may be some way
off (in time, distance or done by someone else).
>> (In the above example, I had to rearrange things so that 64-bit values
>> were at 64-bit offsets, which was probably better, but there was nothing
>> wrong with the original alignment that I could see. It didn't make the
>> x86 version any faster.)
>
> 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.)
--
bartc
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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