C structs & A question about octet

[Peter S. Shenkin]

In article <sun.8943> guy at sun.uucp (Guy Harris) writes:

> [words to the effect that structures are internally padded so that members
> wind up on word-boundaries most efficient for that machine]

>> For all of you that knew this, you're all saying big deal, so what?  Well,
>> I do (did) stuff like this all the time:
>> 
>>     head = (three_bytes*)calloc(N, sizeof(three_bytes));
>> 
>> This wastes N bytes.  Sometimes N is around 10 to the 7th or 8th.  Bad news.
>> ...Anyone have any comments or suggestions?
>
>Allocating arrays that big is relatively uncommon; C's padding rules make
>the more common cases work well, and as such are doing the right thing.  I'd
>suggest you allocate 3*N bytes as a single array, and then extract the
>"short" yourself....

Another way to do it:  put your short and your char in different structures,
and allocate storage for them separately.  The program won't be as easy to
read, and you won't feel virtuous (what, don't YOU feel virtuous when you
write a well-structured program?), but as Guy points out this is a time/storage 
trade-off, made by most (if not all) C compilers in favor of time, and at the 
expense of storage.  Even if you had a compiler which allowed you to resolve
the issue in favor of storage, doing it that way would significantly, perhaps
prohibitively, increase the execution time, assuming you really do have to
do something to all those structure elements beyond allocating space for them.

Time/storage is the best-known trade-off in the programming world, but there 
are others; for instance, programming_ease/program_performance and 
program_readability/program_performance.  Yours is obviously a case of the 
latter, and to some extent of the former as well.

Peter S. Shenkin	 Columbia Univ. Biology Dept., NY, NY  10027
{philabs,rna}!cubsvax!peters		cubsvax!peters at columbia.ARPA