Messages in this thread | | | Date | Sat, 04 Aug 2012 00:20:02 +0200 | From | Sasha Levin <> | Subject | Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable |
| |
On 08/03/2012 11:48 PM, Tejun Heo wrote: > Hello, > > On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote: >> I forgot to comment on that one, sorry. >> >> If we put hash entries after struct hash_table we don't take the >> bits field size into account, or did I miss something? > > So, if you do the following, > > struct { > struct { > int i; > long ar[]; > } B; > long __ar_storage[32]; > } A;
struct A should have been an union, right?
> It should always be safe to dereference A.B.ar[31]. I'm not sure > whether this is something guaranteed by C tho. Maybe compilers are > allowed to put members in reverse order but I think we already depend > on the above.
why is accessing A.B.ar[31] safe?
__ar_storage is only 32*sizeof(long) bytes long, while struct B would need to be 32*sizeof(long) + sizeof(int) bytes long so that A.B.ar[31] access would be safe.
> Thanks. >
| |