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]

aa*****@gmail.com writes:

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?

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[aarklon]

On Apr 4, 9:38*pm, Keith Thompson <[e-mail]:

[e-mail] writes:

*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?

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

[Walter Roberson]

In article <f6**********************************@1g2000prg.go oglegroups.com>,
<aa*****@gmail.comwrote:

>On Apr 4, 9:38=A0pm, Keith Thompson <[e-mail]:

>[e-mail] writes:

=A0arrays 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. =A0That type may have padding bits. =A0Is that what you're
asking?

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.
--
"He wove a great web of knowledge, linking everything together,
and sat modestly at a switchboard at the center, eager to help."
-- Walter Kerr

[Default User]

aa*****@gmail.com wrote:

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]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <f6**********************************@1g2000prg.go oglegroups.com>,
<aa*****@gmail.comwrote:

>>On Apr 4, 9:38=A0pm, Keith Thompson <[e-mail]:

>>[e-mail] writes:
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. =A0That type may have padding bits. =A0Is that what you're
asking?

>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).

[...]

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Andrey Tarasevich]

aa*****@gmail.com wrote:

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.

--
Best regards,
Andrey Tarasevich

[CBFalconer]

aa*****@gmail.com wrote:

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

No they are not.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

aa*****@gmail.com wrote:

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

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.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>aa*****@gmail.com wrote:

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

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, 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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com

[Andrey Tarasevich]

CBFalconer wrote:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>aa*****@gmail.com wrote:

arrays are guaranteed to be contiguous with no padding before
or after any array member , but what about enums ..???
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, 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.

--
Best regards,
Andrey Tarasevich

[Richard Tobin]

In article <47***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>>>arrays are guaranteed to be contiguous with no padding before
or after any array member

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
--
:wq

[CBFalconer]

Richard Tobin wrote:

CBFalconer <cb********@maineline.netwrote:

>>>>arrays are guaranteed to be contiguous with no padding before
or after any array member

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com

[Robbie Hatley]

"aarklon at gmail dot com" blythely made this abstraction error:

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

Arrays are objects.

Enums are types.

Objects may have padding, or they may not.

Types, on the other hand, are incapable of either "having"
or "not having" padding.

Perhaps you're confused by the fact that enums are declared
using curly braces and lists of constant names, like so:

enum Robbie
{
Alpha,
Bravo,
Charlie,
Delta,
Echo,
Foxtrot,
Golf
};

That just defines "Alpha" as an alias for "0", "Bravo"
as an alias for "1", etc. It does not store any data,
so there's no place to put any padding.

Compare that to a struct instance:

struct Bobbie
{
char Tom;
int Jack;
} Fred;

Object Fred will have (on most 32-bit machines and compilers)
8 bytes: 1 byte for Tom, 3 bytes of padding, and 4 bytes for
Jack. That's so that the members of Fred start on word
boundaries ("word" meaning the width of the CPU's registers).
Makes the compiled program more efficient.

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant