Volatility of padding bytes?

[Francine.Neary]

Consider the following situation. I have a large static array s[] of
structs, say of size 500. I also need a smaller array of chars, say of
size 100, which has nothing to do with the struct.

To conserve memory, I'd like if possible to use (after checking with
offsetof and sizeof that there's enough padding to fit a char -
usually it will be) space between fields in the structs to store these
chars. If the padding is between fields s.a and s.b then I could take
my nth char to be at ((char *) &s[n].a)+sizeof(s[n].a).

For this to work, I'd need to know:
1) changing the padding bytes won't affect how the implementation
interprets the struct
2) the implementation won't overwrite padding bytes itself when
manipulating the struct
Are these things guaranteed?

 

[jacob navia]

(e-mail address removed) a écrit :

 

[Roberto Waltman]

Consider the following situation. I have a large static array s[] of
structs, say of size 500. I also need a smaller array of chars, say of
size 100, which has nothing to do with the struct.

To conserve memory, I'd like if possible to use (after checking with
offsetof and sizeof that there's enough padding to fit a char -
usually it will be) space between fields in the structs to store these
chars. If the padding is between fields s.a and s.b then I could take
my nth char to be at ((char *) &s[n].a)+sizeof(s[n].a).

For this to work, I'd need to know:
1) changing the padding bytes won't affect how the implementation
interprets the struct
2) the implementation won't overwrite padding bytes itself when
manipulating the struct
Are these things guaranteed?

(2) Is not. A structure assignment could be implemented, for example,
using memcpy() internally.

Instead of making your code unreadable and hard to understand, why not
make the padding bytes 'visible' ?

For example, if your original struct was

struct s {
char c; /* assume 8 bits */
/* 1 byte padding here */
short s; /* assume 16 bits */
/* two bytes padding here */
long l; /* assume 32 bits */
};

(Typical for many 32 bit architectures)

rewrite it as:

struct s_new_and_improved {
char c;
char padding1;
short s;
char padding[2];
long l;
};

better yet, if you can rearrange the fields:

struct s_latest_and_greatest {
long l;
short s;
char c;
char padding[3];
};


Roberto Waltman

[ Please reply to the group,
return address is invalid ]

 

[Ian Collins]

Consider the following situation. I have a large static array s[] of
structs, say of size 500. I also need a smaller array of chars, say of
size 100, which has nothing to do with the struct.

To conserve memory, I'd like if possible to use (after checking with
offsetof and sizeof that there's enough padding to fit a char -
usually it will be) space between fields in the structs to store these
chars. If the padding is between fields s.a and s.b then I could take
my nth char to be at ((char *) &s[n].a)+sizeof(s[n].a).

For this to work, I'd need to know:
1) changing the padding bytes won't affect how the implementation
interprets the struct
2) the implementation won't overwrite padding bytes itself when
manipulating the struct
Are these things guaranteed?

Why don't you reorder the struct to eliminate the padding?

 

[Francine.Neary]

(e-mail address removed) a écrit :

Consider the following situation. I have a large static array s[] of
structs, say of size 500. I also need a smaller array of chars, say of
size 100, which has nothing to do with the struct.

To conserve memory, I'd like if possible to use (after checking with
offsetof and sizeof that there's enough padding to fit a char -
usually it will be) space between fields in the structs to store these
chars. If the padding is between fields s.a and s.b then I could take
my nth char to be at ((char *) &s[n].a)+sizeof(s[n].a).

For this to work, I'd need to know:
1) changing the padding bytes won't affect how the implementation
interprets the struct
2) the implementation won't overwrite padding bytes itself when
manipulating the struct
Are these things guaranteed?

Did you mean to post a reply?

 

[Francine.Neary]

Consider the following situation. I have a large static array s[] of
structs, say of size 500. I also need a smaller array of chars, say of
size 100, which has nothing to do with the struct.

To conserve memory, I'd like if possible to use (after checking with
offsetof and sizeof that there's enough padding to fit a char -
usually it will be) space between fields in the structs to store these
chars. If the padding is between fields s.a and s.b then I could take
my nth char to be at ((char *) &s[n].a)+sizeof(s[n].a).

For this to work, I'd need to know:
1) changing the padding bytes won't affect how the implementation
interprets the struct
2) the implementation won't overwrite padding bytes itself when
manipulating the struct
Are these things guaranteed?

(2) Is not. A structure assignment could be implemented, for example,
using memcpy() internally.

Instead of making your code unreadable and hard to understand, why not
make the padding bytes 'visible' ?

For example, if your original struct was

struct s {
char c; /* assume 8 bits */
/* 1 byte padding here */
short s; /* assume 16 bits */
/* two bytes padding here */
long l; /* assume 32 bits */
};

(Typical for many 32 bit architectures)

rewrite it as:

struct s_new_and_improved {
char c;
char padding1;
short s;
char padding[2];
long l;

};

Well, as I mentioned the chars I want to store in the padding bytes
don't have any relationship with the struct, so it seems to me it
would make the code quite confusing to include them as fields.

 

[Francine.Neary]

Consider the following situation. I have a large static array s[] of
structs, say of size 500. I also need a smaller array of chars, say of
size 100, which has nothing to do with the struct.

To conserve memory, I'd like if possible to use (after checking with
offsetof and sizeof that there's enough padding to fit a char -
usually it will be) space between fields in the structs to store these
chars. If the padding is between fields s.a and s.b then I could take
my nth char to be at ((char *) &s[n].a)+sizeof(s[n].a).

For this to work, I'd need to know:
1) changing the padding bytes won't affect how the implementation
interprets the struct
2) the implementation won't overwrite padding bytes itself when
manipulating the struct
Are these things guaranteed?

Why don't you reorder the struct to eliminate the padding?

What if this is impossible? Or if the padding is at the end of the
struct?

 

[Ian Collins]

Consider the following situation. I have a large static array s[] of
structs, say of size 500. I also need a smaller array of chars, say of
size 100, which has nothing to do with the struct.

To conserve memory, I'd like if possible to use (after checking with
offsetof and sizeof that there's enough padding to fit a char -
usually it will be) space between fields in the structs to store these
chars. If the padding is between fields s.a and s.b then I could take
my nth char to be at ((char *) &s[n].a)+sizeof(s[n].a).

For this to work, I'd need to know:
1) changing the padding bytes won't affect how the implementation
interprets the struct
2) the implementation won't overwrite padding bytes itself when
manipulating the struct
Are these things guaranteed?

Why don't you reorder the struct to eliminate the padding?

What if this is impossible? Or if the padding is at the end of the
struct?

Unlikely unless you have to match some external format and even if you
did, an external format is unlikely to have padding.

If the padding as at the end, it will be short.
*Please* don't quote signatures.

 

[Richard Bos]

Why don't you reorder the struct to eliminate the padding?

Because that's not always possible, for various reasons.

Richard

 

[jaysome]

Consider the following situation. I have a large static array s[] of
structs, say of size 500. I also need a smaller array of chars, say of
size 100, which has nothing to do with the struct.

To conserve memory, I'd like if possible to use (after checking with
offsetof and sizeof that there's enough padding to fit a char -
usually it will be) space between fields in the structs to store these
chars. If the padding is between fields s.a and s.b then I could take
my nth char to be at ((char *) &s[n].a)+sizeof(s[n].a).

For this to work, I'd need to know:
1) changing the padding bytes won't affect how the implementation
interprets the struct
2) the implementation won't overwrite padding bytes itself when
manipulating the struct
Are these things guaranteed?

Your idea sounds tenuous at best and dangerously volatile at worst.
Forget about any concept of portability. You'd have a lot of
explaining to do if you worked for me and presented this idea (I'm
open to anything).

It would be best if you showed us your definition of your struct type
and also give us information on the sizes of the basic types for your
implementation and any typedefs you have defined that are used in your
struct definition, as well as the value of CHAR_BIT (a macro defined
in the standard header <limits.h>). Give us the results of at least
the following on your implementation, and any other types you happen
to use in your struct definition (e.g., sizeof(void*)):

sizeof(short)
sizeof(int)
sizeof(long)
sizeof(float)
sizeof(double)
sizeof(size_t)
CHAR_BIT

For good measure, include the following:

sizeof(char)
sizeof(signed char)
sizeof(unsigned char)

Regards

 

[pete]

jaysome wrote:

For good measure, include the following:

sizeof(char)
sizeof(signed char)
sizeof(unsigned char)

What's that all about?

 

[jaysome]

What's that all about?

Keeping the honest people honest

 

[swengineer001]

Well, as I mentioned the chars I want to store in the padding bytes
don't have any relationship with the struct, so it seems to me it
would make the code quite confusing to include them as fields.- Hide quoted text -

If the values have nothing to do with the structure what makes you
think including them in the padding is any less confusing than
including them as fields in the structure. Sounds to me like you might
want to rethink putting them in this structure at all.

 

[smanohar]

For this to work, I'd need to know:
1) changing the padding bytes won't affect how the implementation
interprets the struct

Yes. It can be done.

2) the implementation won't overwrite padding bytes itself when
manipulating the struct
Are these things guaranteed?

It can be guaranteed if you make sure that your code doesn't has any
structure assignments and memcpy( ) of the structure.

Please let me know if my understanding is wrong.

 

[Eric Sosman]

Yes. It can be done.

It can be guaranteed if you make sure that your code doesn't has any
structure assignments and memcpy( ) of the structure.

Please let me know if my understanding is wrong.

It's wrong.

"When a value is stored in an object of structure or
union type, including in a member object, the bytes
of the object representation that correspond to any
padding bytes take unspecified values."
-- ISO/IEC 9899:1999(E), section 6.2.6.1, paragraph 6