Compiler error for "wrong" sized type

[David White]

The size of a struct can be affected by compiler packing. Suppose you need it to be a
specific value for some reason (e.g., in firmware). How can you get the compiler to
generate an error for the wrong size rather than assert it at run-time? Here is one way,
but I don't know if it's guaranteed to work on any compiler:
1/(sizeof(struct my_struct) == correct_size);

For me, the above produces a compile-time divide-by-zero error for the wrong size. Is
there a better way?

DW

[Richard Heathfield]

David White said:

The size of a struct can be affected by compiler packing. Suppose you need
it to be a specific value for some reason (e.g., in firmware). How can you
get the compiler to generate an error for the wrong size rather than
assert it at run-time? Here is one way, but I don't know if it's
guaranteed to work on any compiler: 1/(sizeof(struct my_struct) ==
correct_size);

For me, the above produces a compile-time divide-by-zero error for the
wrong size. Is there a better way?

Well, I don't know about "better", but I like this:

char DetectWrongSize[(sizeof(struct my_struct) == correct_size) * 2 - 1];

If the struct is the wrong size, this will yield a negatively sized array,
which is illegal.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Tomás]

David White posted:

The size of a struct can be affected by compiler packing. Suppose you
need it to be a specific value for some reason (e.g., in firmware). How
can you get the compiler to generate an error for the wrong size rather
than assert it at run-time? Here is one way, but I don't know if it's
guaranteed to work on any compiler: 1/(sizeof(struct my_struct) ==
correct_size);

For me, the above produces a compile-time divide-by-zero error for the
wrong size. Is there a better way?

DW

To eliminate the padding (i.e. store each member exactly where you want it),
you could use pointer trickery.

For example, instead of having:

typedef struct Monkey {
int i;
char b;
int j;
};

You could have the following. (It's not pretty, but you could clean it up
and give it a nice interface).
typedef char Monkey[ 2 * sizeof(int) + 1 ];
And then you have functions to access each member:

void SetI( Monkey* const m, int const val )
{
*( (int*)m ) = val;
}

int GetI( const Monkey* const m )
{
return *( (const int*)m );
}

void SetB( Monkey* const m, char const val )
{
*( (char*)m + sizeof(int) ) = val;
}

char GetB( const Monkey* const m )
{
return *( (const char*)m + sizeof(int) );
}

void SetJ( Monkey* const m, int const val )
{
*( (int*)( (char*)m + sizeof(int) + 1 ) ) = val;
}

int GetJ( const Monkey* const m )
{
return *( (const int*)( (const char*)m + sizeof(int) + 1 ) );
}
-Tomás

[Keith Thompson]

"Tomás" <NU**@NULL.NULL > writes:
[...]

To eliminate the padding (i.e. store each member exactly where you want it),
you could use pointer trickery.

For example, instead of having:

typedef struct Monkey {
int i;
char b;
int j;
};

You could have the following. (It's not pretty, but you could clean it up
and give it a nice interface).
typedef char Monkey[ 2 * sizeof(int) + 1 ];
And then you have functions to access each member: [snip] void SetJ( Monkey* const m, int const val )
{
*( (int*)( (char*)m + sizeof(int) + 1 ) ) = val;
}

int GetJ( const Monkey* const m )
{
return *( (const int*)( (const char*)m + sizeof(int) + 1 ) );
}

This access a misaligned int. On many systems, it will cause a trap.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Bill Pursell]

Tomás wrote(in reference to structure padding):

To eliminate the padding (i.e. store each member exactly where you want it),
you could use pointer trickery.

As I read that, the following thought actually fleetingly crossed my
mind:
"That's quite elegant, and eliminates all those annoying padding
problems. Why did C ever bother with the syntactic sugar of structures
and dereferencing members by name?"

I need psychiatric assistance. :)

[David White]

Richard Heathfield wrote:

Well, I don't know about "better", but I like this:

char DetectWrongSize[(sizeof(struct my_struct) == correct_size) * 2 -
1];

If the struct is the wrong size, this will yield a negatively sized
array, which is illegal.

Thanks. That's an improvement. Unfortunately, our Hi-Tech compiler doesn't pick it up
because it treats an array size of -1 as unsigned!

DW

P.S. A colleague is terribly disappointed to learn that an array cannot have a negative
size. He thinks it should be allowed, with the valid index range extending from size+1 to
zero inclusive (e.g., -9 to 0 for a size of -10). I asked him what he would expect for a
sizeof of such an array, but he can't decide whether it should be positive or negative.

[David White]

David White wrote:

with the
valid index range extending from size+1 to zero inclusive (e.g., -9
to 0 for a size of -10).

Make that: size to -1 inclusive (e.g., -10 to -1 for a size of -10).

DW

[Nick Keighley]

David White wrote:

The size of a struct can be affected by compiler packing. Suppose you need it to be a
specific value for some reason (e.g., in firmware). How can you get the compiler to
generate an error for the wrong size rather than assert it at run-time? Here is one way,
but I don't know if it's guaranteed to work on any compiler:
1/(sizeof(struct my_struct) == correct_size);

For me, the above produces a compile-time divide-by-zero error for the wrong size. Is
there a better way?

normally I speak against the Evil of "#prgama pack" and its ilk. Many
compilers
have extensions that tell the compiler to remove packing from specified
structs.
Such extensions are inherently non-portable and you should be very wary
you
don't assign packed to unpacked or vice versa. But for access to
firmware
especially embedded systems I think it can be justified. Embedded
compilers
may be more likely to support such extensions.
--
Nick Keighley

[Richard Heathfield]

David White said:

I asked him what he would expect for a sizeof of such an array, but
he can't decide whether it should be positive or negative.

The size of an array is equal to the number of elements times the size of
each element. Thus, even an array with completely negative indices (were
such an array legal) would have a positive size. Your plane doesn't
suddenly acquire negative weight when you fly across the equator. (It may,
however, flip upside down, depending on who wrote your fbws!)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[David White]

"Nick Keighley" <ni************ ******@hotmail. com> wrote in message
news:11******** **************@ y43g2000cwc.goo glegroups.com.. .

normally I speak against the Evil of "#prgama pack" and its ilk. Many
compilers
have extensions that tell the compiler to remove packing from specified
structs.
Such extensions are inherently non-portable and you should be very wary
you
don't assign packed to unpacked or vice versa. But for access to
firmware
especially embedded systems I think it can be justified. Embedded
compilers
may be more likely to support such extensions.

I also direct my compiler to use zero padding if I need to create literally
millions of instances of a small struct, e.g., in a recursive puzzle-solving
algorithm that generates new states exponentially and the number needed is
unknown, and may exceed available memory. Undesirable as they may be, such
extensions are useful or necessary in some cases (as are other quite nasty
non-standard practices on occasion).

DW