Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)

From: Karsten Blees <karsten.blees@gmail.com>
Date: Dec 9, 2013, 23:19 UTC
Message-ID: <52A64FE9.5010004@gmail.com>
In-Reply-To: <20131209200820.GU29959@google.com>

Am 09.12.2013 21:08, schrieb Jonathan Nieder:

Show 10 quoted lines

> Karsten Blees wrote:
> 
>> GCC supports __packed__ as of 2.3 (1992), so any other compilers
>> that copied the __attribute__ feature probably won't complain.
> 
> Alas, it looks like HP C doesn't support __packed__ (not that I
> care much about HP C):
> 
>  http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/pragmas.htm#Attributes
>

Thanks for the link

> Maybe a macro expanding to __attribute__((aligned(1))) on the fields
> would work?  The same macro could expand to __declspec(align(1)) in
> the MSVC build.
>

But alignment is not the same as packing. We still want the structure to be 8-byte aligned (i.e. variables of the type should start at 8-byte boundaries). We just don't want the size of the structure to be padded to a multiple of 8, so that we can extend it without penalty. (Besides, __attribute__((aligned)) / __declspec(align) can only _increase_ the alignment, so aligned(1) would have no effect).

Googling some more, I believe the most protable way to achieve this via 'compiler settings' is

 #pragma pack(push)
 #pragma pack(4)
 struct hashmap_entry {
   struct hashmap_entry *next;
   unsigned int hash;
 };
 #pragma pack(pop)

This is supported by at least GCC, MSVC and HP (see your link). The downside is that we cannot use macros (in git-compat-util.h) to emit #pragmas. But we wouldn't have to, as compilers aren't supposed to barf on unknown #pragmas.

However, considering the portability issues, the macro solution (injecting just the two fields instead of a struct) becomes more and more attractive in my mind...

Karsten