padding and enums - comp.lang.c

aarklon@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) <kst-u@mib.org> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Apr 4, 9:38=A0pm, Keith Thompson <ks...@mib.org> wrote: > aark...@gmail.com 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 ..???

In article <f6193402-9c76-41b4-bb33-1e4136804cde@1g2000prg.googlegroups.com>, <aarklon@gmail.com> wrote: >On Apr 4, 9:38=A0pm, Keith Thompson <ks...@mib.org> wrote: >> aark...@gmail.com 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

aarklon@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

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes: > In article <f6193402-9c76-41b4-bb33-1e4136804cde@1g2000prg.googlegroups.com>, > <aarklon@gmail.com> wrote: >>On Apr 4, 9:38=A0pm, Keith Thompson <ks...@mib.org> wrote: >>> aark...@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. =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) <kst-u@mib.org> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"

aarklon@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

aarklon@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

CBFalconer <cbfalconer@yahoo.com> writes: > aarklon@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) <kst-u@mib.org> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote: > CBFalconer <cbfalconer@yahoo.com> writes: >> aarklon@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

CBFalconer wrote: > Keith Thompson wrote: >> CBFalconer <cbfalconer@yahoo.com> writes: >>> aarklon@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

CBFalconer <cbfalconer@yahoo.com> writes: > Keith Thompson wrote: >> CBFalconer <cbfalconer@yahoo.com> writes: >>> aarklon@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. 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. -- Keith Thompson (The_Other_Keith) <kst-u@mib.org> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <47F714C0.38DF92EF@yahoo.com>, CBFalconer <cbfalconer@maineline.net> wrote: >>>> 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

Richard Tobin wrote: > CBFalconer <cbfalconer@maineline.net> wrote: > >>>>> 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

"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