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

Re: Git 2.14.1: t6500: error during test on musl libc

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 17, 2017, 03:16 UTC
Message-ID
<xmqq60ciui8o.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<59BDD6AF.5090604@adelielinux.org>
"A. Wilcox" <awilfox@adelielinux.org> writes:
Show 12 quoted lines
>> I did a quick scan for substring "scanf" and read through the 
>> output, and it seems that this is the only one that wants to do
>> the this many characters, e.g. "%42c", conversion.
>> So it seems to me that a real fix has to read the file ourselves
>> and parse up to our HOST_NAME_MAX+1 to see if the hostname refers
>> to us, and fscanf that cannot take "slurp up to this many bytes" is
>> not useful tool to implementing that parsing.
> ...
> Except that is *exactly* *what* *s* *does* (quoting C11 §7.21.6.2):
>
> 9   An input item is defined as the longest sequence of input
>     characters which does not exceed any specified field width
Ah, sorry, I completely misread what you meant.

I thought you were suggesting to replace "%<length>c" with just an unadorned "%s". You meant that we can use "%<length>s" instead. And that solution makes sense. Yes, it is exactly what %<len>s does.

So something like the following would be a sufficient fix, I guess?
Thanks.
-- >8 --
Subject: gc: call fscanf() with %<len>s, not %<len>c, when reading hostname

Earlier in this codepath, we (ab)used "%<len>c" to read the hostname recorded in the lockfile into locking_host[HOST_NAME_MAX + 1] while substituting <len> with the actual value of HOST_NAME_MAX.

This turns out to be incorrect, as it an instruction to read exactly the specified number of bytes. We are trying to read at most that many bytes, we should be using "%<len>s" instead.

Helped-by: A. Wilcox <awilfox@adelielinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin/gc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 3c78fcb9b1..bb2d6c1fb2 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -258,7 +258,7 @@ static const char *lock_repo_for_gc(int force, pid_t* ret_pid)
 		int should_exit;
 
 		if (!scan_fmt)
-			scan_fmt = xstrfmt("%s %%%dc", "%"SCNuMAX, HOST_NAME_MAX);
+			scan_fmt = xstrfmt("%s %%%ds", "%"SCNuMAX, HOST_NAME_MAX);
 		fp = fopen(pidfile_path, "r");
 		memset(locking_host, 0, sizeof(locking_host));
 		should_exit =
Previous: A. WilcoxNext: A. Wilcox
Message 10 of 11 in “Git 2.14.1: t6500: error during test on musl libc”
  1. A. WilcoxSep 15, 2017
  2. Kevin DaudtSep 15, 2017
  3. Kevin DaudtSep 15, 2017
  4. Jeff KingSep 15, 2017
  5. A. WilcoxSep 16, 2017
  6. Rich FelkerSep 16, 2017
  7. Junio C HamanoSep 17, 2017
  8. Szabolcs NagySep 17, 2017
  9. A. WilcoxSep 17, 2017
  10. Junio C HamanoSep 17, 2017
  11. A. WilcoxSep 17, 2017

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.