Re: struct hashmap_entry packing

2014-08-05 Thread Jeff King
On Mon, Aug 04, 2014 at 09:20:02PM +0200, Karsten Blees wrote: I don't see any reason to avoid the packed attribute, if it helps us. As you noted, anything using __attribute__ probably supports it, and if not, we can conditionally #define PACKED_STRUCT or something, like we do for

Re: struct hashmap_entry packing

2014-08-04 Thread Karsten Blees
Am 02.08.2014 00:37, schrieb Jeff King: On Tue, Jul 29, 2014 at 10:40:12PM +0200, Karsten Blees wrote: The sizeof() has to be the same regardless of whether the hashmap_entry is standalone or in another struct, and therefore must be padded up to 16 bytes. If we stored x in that padding in

Re: struct hashmap_entry packing

2014-08-01 Thread Jeff King
On Tue, Jul 29, 2014 at 10:40:12PM +0200, Karsten Blees wrote: The sizeof() has to be the same regardless of whether the hashmap_entry is standalone or in another struct, and therefore must be padded up to 16 bytes. If we stored x in that padding in the combined struct, it would be

Re: struct hashmap_entry packing

2014-07-29 Thread Karsten Blees
Am 28.07.2014 19:17, schrieb Jeff King: Hi Karsten, The hashmap_entry documentation claims: `struct hashmap_entry`:: An opaque structure representing an entry in the hash table, which must be used as first member of user data structures. Ideally it should be