[openssl-dev] [openssl.org #4476] PATCH: fix cast-alignment of "struct lhash_st *"

[Jeffrey Walton]

>> > $ git diff include/openssl/lhash.h
>> > diff --git a/include/openssl/lhash.h b/include/openssl/lhash.h index
>> > 2edd738..5da5054 100644
>> > --- a/include/openssl/lhash.h
>> > +++ b/include/openssl/lhash.h
>> > @@ -180,7 +180,7 @@ void lh_node_usage_stats_bio(const _LHASH *lh, BIO
>> > *out);  # define LHASH_OF(type) struct lhash_st_##type
>> >
>> >  # define DEFINE_LHASH_OF(type) \
>> > -    LHASH_OF(type) { int dummy; }; \
>> > +    LHASH_OF(type) { unsigned long dummy; }; \
>> >      static ossl_inline LHASH_OF(type) * \
>> >          lh_##type##_new(unsigned long (*hfn)(const type *), \
>> >                          int (*cfn)(const type *, const type *)) \
>>
>> Does changing it to "void *dummy" also work?
>
> Not necessarily.  A union might be more comprehensive.
>
>         LHASH_OF(type) {
>             union {
>                 void *v;
>                 unsigned long long ull;
>                 uint64_t u64;
>                 long double ld;
>             } u;
>         };
>
> using whatever types we're sure to have on all supported platforms.

Yeah, that might be better.

I looked at "struct lhash_st" prior to testing, and it looked like the
largest member was a pointer and an unsigned long. Sine the alignment
complaint needed something to move things to 8 bytes and the int was
already present, unsigned long seemed like a good choice.

I'm not sure about the long double, but the larger alignment demand
should be OK. For example, Apple always gives you a 16-byte aligned
pointer (http://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/malloc.3.html),
so using a 4-byte int does not save much in practice since its 16-byte
aligned, too.

Whatever you decide, there's a fair amount of low hanging fruit to be
picked with -Wcast-align.

Jeff