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 p
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
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
4 matches
Mail list logo
