Subject: Re: [PATCH] archive-tar: add UL type suffix to unsigned long constant

From: Ramsay Jones <[email-masked]>
Date: Sat, 18 Jun 2016 02:21:08 +0100

On 18/06/16 00:40, Jeff King wrote:
> On Fri, Jun 17, 2016 at 10:06:14PM +0100, Ramsay Jones wrote:
> 
>> If you need to re-roll your 'jk/big-and-old-archive-tar' branch, could
>> you please squash this into the relevant patch (commit 8035a1e3,
>> "archive-tar: write extended headers for far-future mtime", 16-06-2016).
>>
>> Thanks!
>>
>> ATB,
>> Ramsay Jones
>>
>>  archive-tar.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/archive-tar.c b/archive-tar.c
>> index 749722f..c7b85fd 100644
>> --- a/archive-tar.c
>> +++ b/archive-tar.c
>> @@ -187,7 +187,7 @@ static inline unsigned long ustar_size(uintmax_t size)
>>  
>>  static inline unsigned long ustar_mtime(time_t mtime)
>>  {
>> -	if (mtime < 077777777777)
>> +	if (mtime < 077777777777UL)
> 
> Whoops. I even got it right in the similar line above. :-/
> 
> This did make me wonder how the whole thing fares on a system where
> "unsigned long" is 32-bit (AIUI, Git for Windows is such a system).
> 
> The sizes passed around (here and all through git) are "unsigned long",
> so I don't think we're making anything _worse_.

Heh, I had exactly the same thought! ;-)

I have a TODO item that reads: check odb code for object size limitations
imposed by using 'unsigned long'. This is a known problem on Git for Windows.

[Not for cygwin, however, since long is 64bit (just like linux). The win32api
headers on cygwin have been written in terms of a __LONG32 #define to allow
them to be used on LLP64 and LP64 systems.]

However, since I don't have GFW installed, I couldn't actually test it, so ...

ATB,
Ramsay Jones