[0/4] fix pax extended header length calculation

Message

René Scharfe Aug. 17, 2019, 4:19 p.m. UTC

The code for building pax extended headers has been miscalculating
lengths slightly shorter than powers of 10  since I wrote it in 2006.
That affects entries for paths with a length of 990, 991, 9989, 9990,
9991, 99988 etc. and link targets 4 characters shorter.  Here's a
series for fixing it.

  archive-tar: report wrong pax extended header length
  archive-tar: fix pax extended header length calculation
  archive-tar: use size_t in strbuf_append_ext_header()
  archive-tar: turn length miscalculation warning into BUG

 archive-tar.c                   | 14 ++++++++++----
 t/t5004-archive-corner-cases.sh | 19 +++++++++++++++++++
 2 files changed, 29 insertions(+), 4 deletions(-)

--
2.23.0

Comments

brian m. carlson Aug. 17, 2019, 4:40 p.m. UTC | #1

On 2019-08-17 at 16:19:29, René Scharfe wrote:
> The code for building pax extended headers has been miscalculating
> lengths slightly shorter than powers of 10  since I wrote it in 2006.
> That affects entries for paths with a length of 990, 991, 9989, 9990,
> 9991, 99988 etc. and link targets 4 characters shorter.  Here's a
> series for fixing it.

This series looked good to me. I'm don't completely understand our
technique for computing the length, but the additional tests build my
confidence and your explanation makes sense.

As a side note, I have personally found computing the length of pax
headers to be enormously difficult due to this very edge case, so I'm
not surprised this bug crept in.