🚀 go-pugleaf

Karl Heuer wrote:
> What this really implies is that, if bit arrays are ever supported,
> they won't fit cleanly into the existing language and hence will
> probably not support all the same features as "normal" arrays.

kdb@chinet.chi.il.us (Karl Botts) suggests that sizeof a hypothetical
bit type in C could include padding to the nearest byte.

> This is OK; sizeof produces the amount of storage needed to hold an
> object, not the actual size of the object.  I would expect sizeof
> applied to an array of 8 bits to also return 1, tho of course this
> would be implementation dependent.

While the bit 8-) about padding is true, there are other rules and
assumptions that would break.  Which of the following do you want to
break?  Consider the costs of not breaking on byte-addressed
architectures.

* sizeof array / sizeof array[0] is the number of elements in an array.
  (ANS C standard section 3.3.3.2, "Examples" subsection.)

* "void *" and "char *" have the same representation.
  (3.1.2.3, "Types".)

* a "void *" can store a pointer to any incomplete or object type.
  (3.2.2.3, "Pointers".)

* One of the operands to "[]" shall have type "pointer to object
  TYPE", and the result has type "TYPE".  "E1[E2]" is defined to be
  identical to "(*(E1+(E2)))".
  (3.3.2.1, "Array Subscripting".)
  (Consider the standard
     "for (i = 0; i < NUM; i++)"
  to
     "for (p = &a[0]; p < &a[NUM]; p++)"
  transformation.)
--
Tim McDaniel                 Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Work phone: +1 313 973 1300                        Home phone: +1 313 677 4386
Internet: mcdaniel@adi.com                UUCP: {uunet,sharkey}!amara!mcdaniel