{"thread":{"id":"62832","subject":"[PATCH v2] t8002: fix ambiguous printf conversion specifications","startedAt":"2025-01-20T11:41:36Z","lastAt":"2025-01-21T22:10:17Z","messageCount":2,"participants":["Jan Palus","Junio C Hamano"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"510943","messageId":"20250120114106.2844157-1-jpalus@fastmail.com","threadId":"62832","inReplyTo":null,"subject":"[PATCH v2] t8002: fix ambiguous printf conversion specifications","fromName":"Jan Palus","fromEmail":"jpalus@fastmail.com","sentAt":"2025-01-20T11:41:06Z","receivedAt":"2025-01-20T11:41:36Z","isPatch":true,"sender":{"key":"jpalus@fastmail.com","avatar":"https://avatars.githubusercontent.com/u/484155?v=4"},"body":"In e7fb2ca945 (builtin/blame: fix out-of-bounds write with blank\nboundary commits, 2025-01-10), we have introduced two new tests that\nexpect a certain amount of padding. This padding is generated via\nprintf using the \"%0.s\" conversion specification. That directive is\nambiguous because it might be interpreted as field width (most shells)\nor 0-padding flag for numeric fields (coreutils).\n\nFix this issue by using \"%${N}s\" instead, which is already being\nused in other tests (i.e. t5300, t0450) and is unambiguous.\n\nHelped-by: Patrick Steinhardt <ps@pks.im>\nSigned-off-by: Jan Palus <jpalus@fastmail.com>\n---\n t/t8002-blame.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t8002-blame.sh b/t/t8002-blame.sh\nindex 1ad039e123..e98993276a 100755\n--- a/t/t8002-blame.sh\n+++ b/t/t8002-blame.sh\n@@ -138,7 +138,7 @@ test_expect_success 'blame --abbrev -b truncates the blank boundary' '\n \t# Note that `--abbrev=` always gets incremented by 1, which is why we\n \t# expect 11 leading spaces and not 10.\n \tcat >expect <<-EOF &&\n-\t$(printf \"%0.s \" $(test_seq 11)) (<author@example.com> 2005-04-07 15:45:13 -0700 1) abbrev\n+\t$(printf \"%11s\" \"\") (<author@example.com> 2005-04-07 15:45:13 -0700 1) abbrev\n \tEOF\n \tgit blame -b --abbrev=10 ^HEAD -- abbrev.t >actual &&\n \ttest_cmp expect actual\n@@ -146,7 +146,7 @@ test_expect_success 'blame --abbrev -b truncates the blank boundary' '\n \n test_expect_success 'blame with excessive --abbrev and -b culls to hash length' '\n \tcat >expect <<-EOF &&\n-\t$(printf \"%0.s \" $(test_seq $hexsz)) (<author@example.com> 2005-04-07 15:45:13 -0700 1) abbrev\n+\t$(printf \"%${hexsz}s\" \"\") (<author@example.com> 2005-04-07 15:45:13 -0700 1) abbrev\n \tEOF\n \tgit blame -b --abbrev=9000 ^HEAD -- abbrev.t >actual &&\n \ttest_cmp expect actual\n-- \n2.48.1\n\n"},{"id":"511027","messageId":"xmqqplkfyg1l.fsf@gitster.g","threadId":"62832","inReplyTo":"20250120114106.2844157-1-jpalus@fastmail.com","subject":"Re: [PATCH v2] t8002: fix ambiguous printf conversion specifications","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-21T22:10:14Z","receivedAt":"2025-01-21T22:10:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan Palus <jpalus@fastmail.com> writes:\n\n> -\t$(printf \"%0.s \" $(test_seq 11)) (<author@example.com> 2005-04-07 15:45:13 -0700 1) abbrev\n> +\t$(printf \"%11s\" \"\") (<author@example.com> 2005-04-07 15:45:13 -0700 1) abbrev\n\nThis obviously is much clearer than the obscure original that\nconcatenates \" \" 11 times (for 11 arguments that printf receives).\n\nNice.\n\n> @@ -146,7 +146,7 @@ test_expect_success 'blame --abbrev -b truncates the blank boundary' '\n>  \n>  test_expect_success 'blame with excessive --abbrev and -b culls to hash length' '\n>  \tcat >expect <<-EOF &&\n> -\t$(printf \"%0.s \" $(test_seq $hexsz)) (<author@example.com> 2005-04-07 15:45:13 -0700 1) abbrev\n> +\t$(printf \"%${hexsz}s\" \"\") (<author@example.com> 2005-04-07 15:45:13 -0700 1) abbrev\n\nThe fact that $hexsz was not quoted in the original made me look at\nhow it is defined (as an unquoted variable reference is often a way\nto lose unwanted leading whitespaces, e.g. bytes=$(wc -c <foo) &&\nshow $bytes), but it seems that hexsz would not get any leading (or\ntrailing) whitespaces so this rewrite perfectly fine.\n\nThanks.  Will queue.\n"}]}