padding and enums

[aarklon]

Hi all,

arrays are guaranteed to be contiguous with no padding before or
after any array member , but what about enums ..???

 

[Keith Thompson]

arrays are guaranteed to be contiguous with no padding before or
after any array member , but what about enums ..???

Um, what about them?

An enumerated type is compatible with some implementation-defined
integral type. That type may have padding bits. Is that what you're
asking?

 

[aarklon]

Um, what about them?

An enumerated type is compatible with some implementation-defined
integral type.  That type may have padding bits.  Is that what you're
asking?

I just wanted to clear the doubt that, whether the concept structure
padding also applies to enums ..???

 

[Walter Roberson]

I just wanted to clear the doubt that, whether the concept structure
padding also applies to enums ..???

Your original wording about arrays is not completely correct.
It is possible for there to be padding after the final array member in
a structure. For example:

struct foo { char bar[3]; int baz };

then there could be padding after bar[2] and before baz.


An enumeration type is some integral type (implementation-defined which),
so the same rules apply to it as apply to other integral types.

 

[Default User]

Hi all,

arrays are guaranteed to be contiguous with no padding before or
after any array member , but what about enums ..???

Enumerations are not an aggregate. The concept of padding means nothing
in that context. It seems like you think that declaring an enum means
making some data structure with all those in some sort of sequence. It
doesn't. It creates a type, which is in reality some sort of alias for
one of the integral types, with some predefined aliased values.




Brian

 

[Keith Thompson]

I just wanted to clear the doubt that, whether the concept structure
padding also applies to enums ..???

Your original wording about arrays is not completely correct.
It is possible for there to be padding after the final array member in
a structure. For example:

struct foo { char bar[3]; int baz };

then there could be padding after bar[2] and before baz.

But that padding isn't part of the array. In effect, there can be
padding after the array, but not after an element of an array (a
debatable distinction, but I think that's the best way to look at it).

[...]

 

[Andrey Tarasevich]

I just wanted to clear the doubt that, whether the concept structure
padding also applies to enums ..???

"Structure padding" is something that is inserted between small pieces
(members) of a larger composite object. Such composite objects are
referred as "aggregates" in C. Structures are aggregates, they can have
padding between their members. Arrays are aggregates, although they
cannot have any array-specific padding between their elements.

Enums are not aggregates. They don't consist of smaller pieces. There's
nowhere in enum you can insert that padding to. So I don't see how could
anyone even start applying the concept of "struct padding" to enums.

 

[CBFalconer]

arrays are guaranteed to be contiguous with no padding before or
after any array member , but what about enums ..???

No they are not.

 

[Keith Thompson]

No they are not.

What are not what?

If you're disputing the statement that arrays are guaranteed to be
contiguous, I'm afraid you're mistaken; there can be no padding before
or after any array element. (Depending on the context, there can be
padding before or after the whole array, just as for any object.)

If you're trying to answer the "what about enums" question, I'd like
to know how you've managed to interpret the question so it has a
meaningful yes or no answer.

 

[CBFalconer]

What are not what?

If you're disputing the statement that arrays are guaranteed to
be contiguous, I'm afraid you're mistaken; there can be no
padding before or after any array element. (Depending on the
context, there can be padding before or after the whole array,
just as for any object.)

If, for example, the basic element is an array of 3 bytes, but
requires the alignment of 4, the individual element will be padded
with an extra byte. Something like:

typedef struct elem {
int i;
char c;
} elem;

and, to me, each element of:

elem array[MAX};

will be padded accordingly. This is why such arrays cannot be
compared for equality with simple code.

Yes, I was overly terse AGAIN. Sorry.

 

[Andrey Tarasevich]

If, for example, the basic element is an array of 3 bytes, but
requires the alignment of 4, the individual element will be padded
with an extra byte. Something like:

typedef struct elem {
int i;
char c;
} elem;

Yes, but this really has nothing much to do with the array itself. This
trailing padding exists as an integral part of the above struct, not as
something inserted additionally _between_ the elements of the array and
specific to the the array itself.

For arrays, the following relation must hold

sizeof array = sizeof element * number_of_elements

This eliminates any possibility of the array inserting any additional
padding between its elements. Any necessary padding should be already
present in the element itself (in terms of it size, as returned by
'sizeof').

and, to me, each element of:

elem array[MAX};

will be padded accordingly. This is why such arrays cannot be
compared for equality with simple code.

I'm not really sure what exactly you mean here. But if you are saying
that arrays can't be compared by raw memory comparison because padding
areas might contain unpredictable bit patterns, then first of all this
issue actually already applies to structs. It already exists for
standalone structs, no arrays necessary. And it applies to arrays of
structs just as mere consequence of that, not because of some specific
property of arrays.

If array elements contain no padding of any kind (i.e. if they can be
compared by raw memory comparison), then whole arrays of such elements
can also be compared by raw memory comparison because, once again,
arrays are not allowed to introduce any additional padding between their
elements.

 

[Keith Thompson]

What are not what?

If you're disputing the statement that arrays are guaranteed to
be contiguous, I'm afraid you're mistaken; there can be no
padding before or after any array element. (Depending on the
context, there can be padding before or after the whole array,
just as for any object.)

If, for example, the basic element is an array of 3 bytes, but
requires the alignment of 4, the individual element will be padded
with an extra byte. Something like:

typedef struct elem {
int i;
char c;
} elem;

and, to me, each element of:

elem array[MAX};

will be padded accordingly. This is why such arrays cannot be
compared for equality with simple code.

Yes, I was overly terse AGAIN. Sorry.

First off, your element type isn't an array of 3 bytes. If it were,
it would have to be byte-aligned. For example:

typedef unsigned char tri_byte[3];
tri_byte arr[10];

Type tri_byte cannot require 4-byte alignment, and sizeof arr must be
30 in any conforming implementation. No padding is permitted within
either array type.

As for the example you actually used, I assume you intend
sizeof(int)== 2. If int requires word alignment, then sizeof(struct
elem) must be (at least) 4; padding is inserted within the structure
itself, probably after c (or possibly after i). This padding is
required because of the requirements on arrays, but it applies to all
objects of type struct elem.

Every object type must have a size that's a multiple of its required
alignment. Padding can exist within structures, but not between array
elements.

 

[Richard Tobin]

[/QUOTE]

Note the phrase "before or after".

typedef struct elem {
int i;
char c;
} elem;

and, to me, each element of:

elem array[MAX};

will be padded accordingly.

As you say, each element will be padded. There will be no padding
*before or after* each element. The padding is *in* the elements.

-- Richard

 

[CBFalconer]

Note the phrase "before or after".

typedef struct elem {
int i;
char c;
} elem;

and, to me, each element of:

elem array[MAX};

will be padded accordingly.

As you say, each element will be padded. There will be no padding
*before or after* each element. The padding is *in* the elements.

Alright, I concede. However the array user has to allow for the
fact that there are padding items present.