[oi-dev] Broadcom wireless drivers for OpenIndiana

[Jim Klimov]

On 2013-04-26 09:30, Jean-Pierre wrote:
>> struct io_stack_location {
>> uint8_t isl_major;
>> uint8_t isl_minor;
>> uint8_t isl_flags;
>> uint8_t isl_ctl;
>> ...
>>
>> union {
>> struct {
>> uint32_t isl_len;
>> /* "POINTER_ALIGNMENT" according to msdn */
>> uint32_t *isl_key;
>> uint64_t isl_byteoff;
>> } isl_read;
>> ...

> Tke key element is the attribute "POINTER_ALIGNMENT" on
> the msdn description you copied above. On a 64-bit CPU
> this is supposed to mean alignment to a multiple of 8
> bytes. The attribute is defined for the field isl_key
> (and others), but this recursively implies the outer
> structures and union to also be aligned, otherwise the
> inner alignment would not hold. Compilers are expected
> to care for it.

But in this case you have 4 1-byte values an 1 4-byte value
and then the pointer, doesn't this make the pointer 8-byte
aligned without fillers? (And the isl_len thus starts at
the offset of 4?)

>
> I spent much time on this issue, and I added the checks
> so that other users would not get stuck on it.  (snip)
> I have had to check them in the binary image of the driver,
> so I am pretty sure about them.

Ok, I'll trust your judgement, but my "gut feeling" says
that this may be a source of problems with my compilations...
Or maybe that some other structures need to be validated
similarly.

Also, isn't it possible to use some compiler pragma to
enforce proper (er, microsoft-expected) alignment of
these structures' fields?

Thanks
//Jim