#C structure size
9 messages in this thread
Larry,
That's comforting.
I'm not sure who sent the original message I replied to, but I'm an
observer on the C standards committee, X3J11. I have the latest spec here
dated 2/14/90. In section 3.3.3.4, describing the sizeof operator, it sez
"… When applied to an operand that has structure oion type, the result is
the total number of bytes in such an object, INCLUDING internal and
trailing padding." [editorial emphasis]
Now, I think that ALL structures should be padded to the machine's
natural word size, even ones with 3 bytes in them. This is so that the
environment can use word moves when copying the things (as in assignment,
argument passing, etc.) Now maybe that will cause a few eyebrows to raise!
But I find it silly that the Whitesmiths compiler we use at work on our
68020's copies ALL structures using byte moves (ugh!). I haven't looked at
the Amiga compilers yet to see what they do.
🙂
Jerry.
Jerry,
One of the earliest problems I had with C was due to padding that did not
explicitly show up in the structure definition. I was accessing the struct
with an assembler routine, and the pad byte (in the MIDDLE of a struct)
nailed me real good. Of course it really was my fault for not looking at
the assembler version of the struct.
I guess padding, if it must be applied, should probably be done for all
things, including 'all byte' structs, mainly because of the speed penalty,
not only in having to copy on a byte basis, but also to keep the natural
alignment for speed on the 68020 and 68030.
-larry
All structures are always padded to word alignment on 68k compilers. The
reason of course is to ensure that you don't access an int or long on an
odd-address boundary by mistake. For example:
struct foo {
int a;
char b;
} bar[2];
Here, the sizeof(struct foo) _must_ be 4 (assuming 16-bit ints, of course
8-), so that when you say bar[1].a you're getting the 'a' element on an
even boundary.
-Mike
Mike,
How's that 5.0b release coming? Do I gotta make a phone call in order
to get it?
Anxiously awaiting,
Jerry.
Coding for 5.0b is done, we're more or less waiting for other external
forces to finish.
Late breaking news: 5.0b is going to be an interim essentials-fixed only
release, and should be available next week. In essence, it'll contain a
new compiler, libraries, and SDB. There'll be no charge for the update,
although you'll have to call our sales dept. to get it (800)221-0440.
Version 5.1 will pretty much update everything, little and small, and will
be available a bit after 5.0b is out.
In short, 5.0b is a quick-fix release to get rid of the real nasty SDB and
compiler bugs. 5.1 will be the whole ball of wax.
-Mike
Mike,
The way you worded your message about the 5.0b and 5.1 releases, I get
the impression that while 5.0b will be a no-cost upgrade, that 5.1 will
not. Is this correct? Wrong? Premature?
Inquiring minds want to know 🙂
…BobR
White Wolf Productions
5.1 will probably be a shipping & handling charge upgrade (about $10 or
$15). 5.0b will of course be no-cost.
-Mike
Larry,
I have several pieces of code that share structures between C and ASM.
I've found best results from explictly padding all structures myself,
and/or arranging them so that they don't need padding, if at all possible.
Besides, longword aligning all pointers and ints translates into great
speed advantages when running on an '020 and up. (God I hate List Nodes for
placing the name pointer on an odd word boundry!)
Dean
DKB Software
Dean,
Yes, I agree. Alignment is very important. I can't help but have the
feeling though, that the programmer should be the one specifying the
alignment. I didn't realize that about List Nodes. Not Nice.
-larry