Re: sys/dev/scsipi/scsipi_base.c

[Alan Barrett <apb%cequrux.com@localhost>]

On Sun, 06 Jan 2008, David Laight wrote:
> > memcpy(inqbuf->vendor, "ADAPTEC ACB-4000            ", 28);
> > yet inqbuf->vendor is declared in struct scsipi_inquiry_data as:
> > char    vendor[8];
> and is followed by:
>   char    product[16];
>   char    revision[4];
> so the memcpy updates all 3 fields :-)

This is rather ugly, but it's either guaranteed to work, or will work
with all except the most perverse C language implementations.

The C99 standard (I have the WG14/N1124 draft) says, in section 6.7.2.1
paragraph 5, that storage for members of a structure are allocated in an
ordered sequence; and paragraph 13 says that the members have addresses
that increase in the order in which they are declared.

Section 6.7.2.1 paragraph 12 says that structure members are aligned in
an implementation-defined manner appropriate to their type.

Section 6.7.2.1 paragraph 13 says that there may be unnamed padding
within a structure.

Now, "aligned ... appropriate to its type" means that a char array is
aligned to char boundaries.  This implies that two adjacent char array
members in a struct will have adjacent addresses.  I can't find an
explicit prohibition against gratuitous padding that's not actually
required to satisfy aligment constraints, but section 7.21.4 footnote
265 implies that padding in structures is "for purposes of alignment".
So, even if this is not guaranteed to work, it would take a very
perverse implementation to add unwanted padding between char arrays in
structs.

--apb (Alan Barrett)