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
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
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
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
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 followed by an int-sized member to prevent
5 matches
Mail list logo
