git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 14, 2016, 20:22 UTC
Message-ID
<xmqqbn20otqu.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20160714201018.GA18372@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 19 quoted lines
>> +#if ULONG_MAX == 0x7FFFFFFF
>> +#define USTAR_MAX_SIZE ULONG_MAX
>> +#define USTAR_MAX_MTIME ULONG_MAX
>> +#else
>>  #define USTAR_MAX_SIZE 077777777777UL
>>  #define USTAR_MAX_MTIME 077777777777UL
>> +#endif
>>  
>>  /* writes out the whole block, but only if it is full */
>>  static void write_if_needed(void)
>
> If for some reason we are wrong that objects cannot be larger than
> ULONG_MAX (e.g., later on we convert everything to size_t, and 64-bit
> LLP platforms handle large objects just fine), then we would prematurely
> switch to extended headers on those platforms.
>
> I think that's OK. This would just need cleaned up as part of the
> conversion from "unsigned long" to "size_t" (the correct check would
> then be against the max size_t).
> Also, shouldn't it be checking against 0xFFFFFFFF?
Correct.  Somehow I thought I was checking with LONG_MAX.  Will correct.
> An easier check would be "sizeof()", but I guess we can't use that in a
> preprocessor directive.
Yes, I tried it and failed ;-)
Show 9 quoted lines
>> -test_expect_success TAR_HUGE 'system tar can read our huge size' '
>> +test_expect_success TAR_HUGE,64BIT 'system tar can read our huge size' '
>
> The 64BIT prereq is really "unsigned long is 64-bit". I wonder if we
> should call it UL64 or something like that to make it more clear.
>
> That makes it unnecessarily tied-in with the implementation, but it does
> make it more clear what we care about; the distinction matters for
> things like LP64 vs LLP64.

I do not think any platform is weird enough to have different sizes for long and ulong, so I am not sure you need UL64.

But pointer size can legitimately be different, so it has a value to differentiate between LP64 and LLP64, if we start doing things like "does this platform have large virtual address space?"

LONG_IS_64BIT perhaps to be more readable?
Previous: Jeff KingNext: Jeff King
Message 32 of 42 in “friendlier handling of overflows in archive-tar”
  1. 0/5 friendlier handling of overflows in archive-tarJeff King, Jun 30, 2016
  2. 5/5 archive-tar: drop return valueJeff King, Jun 30, 2016
  3. 3/5 archive-tar: write extended headers for file sizes >= 8GBJeff King, Jun 30, 2016
  4. Johannes SixtJul 14, 2016
  5. Junio C HamanoJul 14, 2016
  6. Jeff KingJul 14, 2016
  7. Torsten BögershausenJul 15, 2016
  8. 4/5 archive-tar: write extended headers for far-future mtimeJeff King, Jun 30, 2016
  9. 1/5 t9300: factor out portable "head -c" replacementJeff King, Jun 30, 2016
  10. Eric SunshineJul 1, 2016
  11. Junio C HamanoJul 1, 2016
  12. Jeff KingJul 1, 2016
  13. 6/5 t5000: use test_match_signalJeff King, Jun 30, 2016
  14. 2/5 t5000: test tar files that overflow ustar headersJeff King, Jun 30, 2016
  15. Johannes SchindelinJul 14, 2016
  16. Johannes SixtJul 14, 2016
  17. Junio C HamanoJul 14, 2016
  18. Johannes SixtJul 14, 2016
  19. Jeff KingJul 14, 2016
  20. Junio C HamanoJul 14, 2016
  21. Jeff KingJul 14, 2016
  22. Torsten BögershausenJul 15, 2016
  23. Jeff KingJul 15, 2016
  24. Junio C HamanoJul 14, 2016
  25. Jeff KingJul 14, 2016
  26. Jeff KingJul 14, 2016
  27. Junio C HamanoJul 14, 2016
  28. Junio C HamanoJul 14, 2016
  29. Jeff KingJul 14, 2016
  30. Junio C HamanoJul 14, 2016
  31. Jeff KingJul 14, 2016
  32. Junio C HamanoJul 14, 2016
  33. Jeff KingJul 14, 2016
  34. Junio C HamanoJul 14, 2016
  35. 0/2 ulong may only be 32-bit wideJunio C Hamano, Jul 14, 2016
  36. 2/2 archive-tar: huge offset and future timestamps would not work on 32-bitJunio C Hamano, Jul 14, 2016
  37. Jeff KingJul 14, 2016
  38. Junio C HamanoJul 14, 2016
  39. Duy NguyenJul 16, 2016
  40. 1/2 t0006: skip "far in the future" test when unsigned long is not long enoughJunio C Hamano, Jul 14, 2016
  41. Johannes SchindelinJul 15, 2016
  42. Junio C HamanoJul 15, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.