question about an array of enum
Tim McDaniel
mcdaniel at adi.com
Sat Nov 10 03:16:00 AEST 1990
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 at 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 at adi.com UUCP: {uunet,sharkey}!amara!mcdaniel
More information about the Comp.std.c
mailing list