From: utzoo!decvax!cca!gwyn@Brl@sri-unix Newsgroups: net.unix-wizards Title: Re: C sizeof Article-I.D.: sri-unix.3029 Posted: Wed Sep 1 00:55:40 1982 Received: Thu Sep 9 06:00:46 1982 From: Doug GwynDate: 26 Aug 82 3:58:13-EDT (Thu) Welcome to the hole-in-the-struct club. On a PDP-11, struct { char a; long b; /* not "int" whose size varies a lot */ } has to have a "padding" char so that the next MOS starts on a word (2-byte) boundary, due to hardware restrictions (infamous "odd address trap"). Also, total struct size will always be even so that arrays of structs obey the hardware restrictions too. On the VAX this garbage is TOTALLY UNNECESSARY but some PCC implementor apparently decided to squeeze a few nanoseconds out of the hardware by longword (4-byte) aligning longs, floats, and doubles. What burns me about this is that it isn't even PDP-11 compatible so your binary files will very likely not be accessible to the SAME C code on the VAX, and there is no easy fix for this (contrary to initial appearances). sizeof thing always includes any alignment padding, so an array of n things will have sizeof array == n * sizeof thing. I/O of a padded struct does read/write the padding as well as the useful data if you do something like write( 1, &thing, sizeof thing ); whereas to avoid the padding you would have to access MOSs separately: write( 1, &thing.a, sizeof thing.a ); write( 1, &thing.b, sizeof thing.b ); Nothing can be done in general about this problem, since there are CPU architectures that necessitate alignment (IBM 360 is maybe the worst). It is a pity, though, that the VAX implementation is unnecessarily ugly.