>> > $ 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 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev