Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Pascal --> C question
Message-ID: <760@cresswell.quintus.UUCP>
Date: 11 Mar 88 11:32:41 GMT
References: <650001@hpcilzb.HP.COM> <4940001@hpiacla.HP.COM> <3353@psuvax1.psu.edu>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 29

In article <3353@psuvax1.psu.edu>, schwartz@gondor.cs.psu.edu (Scott Schwartz) writes:
> The "packed" thing has a special meaning.  I can't quote you from the
> ANSI or ISO standards offhand, but the idea is that the compiler is
> supposed to arrange that the packed structure takes up a minimal amount
> of space (probably subject to some alignment restrictions).  So in the
> example I gave each boolean would take up one bit, and there would be
> 1024 of them, the whole array taking up 128 bytes.

The trouble is that a Pascal compiler is absolutely free to ignore
'packed' entirely.  When you say
	var a: array [0.1023] of boolean;
you have no guarantee at all that the compiler won't use 1024 "words".
To quote the Berkeley Pascal manual page:
    "The keyword 'packed' is recognized but has no effect."
You would be lucky to find a Pascal compiler which will pack array
elements down to the bit level.  Byte level, yes.

The situation is better in C for two reasons.
(1) At least you can say
	char a[1024];
    and get nothing worse than byte packing.

(2) You can write the bit-extraction operations as macros, and use them
    over and over again on different arrays.

And of course there are those C compilers which have the "inline"
processor, so that you can have
	get_bit(array, index)
and	put_bit(array, index, value)
turned into your machine's instructions for bit access.  (Yay, Sun!)