> * 106: This will massively over-allocate:
>
> uint64_t buf[IEEE80211_MTU_MAX]; /* aligned on
> ed on 64-bit boundary */
>
> You need:
>
> uint64_t buf[IEEE80211_MTU_MAX / sizeof
> izeof (uint64_t)];
Given rounding down in integer division, you must be assuming that
the constant is an integer multiple of sizeof(uint64_t).
If you added +1 right before the close square brackets,
that wouldn't be an issue (unless it was important that
the buffer be just the right size and no larger lest someone
use sizeof on the buffer and ask for trouble, in which case
you'd still have a problem if it isn't an integer multiple). It may all
be moot in this case, but it looks to me like a potential booby trap
in the face of future maintenance. I would think that the safest,
most portable, and least tricky approach might be:
struct {
uint64_t pad; /* force alignment */
uint8_t uf[IEEE80211_MTU_MAX]; /* array exactly the right size and type */
} b;
#define buf b.uf
That of course wastes the storage for pad, but doesn't do too much evil
I can see otherwise, and makes less assumptions. (struct name and
member name could probably be better chosen, but that's not the
point)
Most efficient but non-portable would be to use whatever #pragma or
other external-to-the-language gizmos the compilers to be supported
(Studio and gcc at least, I would think) offer to force alignment, #ifdef'd
to work with at least those two. But I personally think that's even uglier
than the struct example I gave, unless strictly necessary.
This message posted from opensolaris.org
