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 _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
