From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from secure.elehost.com (secure.elehost.com [185.209.179.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98715185B for ; Sun, 11 Feb 2024 02:47:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.209.179.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707619646; cv=none; b=Lbl9CQgr/KbF0ehQu0gh1s22SABvZLIN4DbIub6vk35x2YIKn+wYZSGF7BXp7sp+gUe4OsbkVN6zA/uUnERodUJn5h6nWCRAB/I6u9d8LTXsVMDlhSaGz+QwE+GTTnLWXe05rGUSpJjHnvmOB61ictXa77UYIG4HyQIt6nnRKvA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707619646; c=relaxed/simple; bh=651Gifi1sDC3k2IuYxOWxnfOyeyJwBsujZzo/HsSHBE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=frMzrvDH+QdT3sIF0Tew+5gERom01+PQYJBYEsSSFFeFMz3ckzgRbjT1mWJMZ4I66WF3c+zMd1Ayo9Z9/EV1mS1tnuzVJCEKaev9nAK+EoMm80ibvaXaWBkvr4iwRFfPoEeWMaCS2GZNc+L0d58yqDnnKJNf1fh7FQleVTI00yE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nexbridge.com; spf=pass smtp.mailfrom=nexbridge.com; arc=none smtp.client-ip=185.209.179.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nexbridge.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexbridge.com X-Virus-Scanned: Debian amavisd-new at secure.elehost.com Received: from Mazikeen (cpebc4dfb928313-cmbc4dfb928310.cpe.net.cable.rogers.com [99.228.251.108] (may be forged)) (authenticated bits=0) by secure.elehost.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 41B2lJwY3341557 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 11 Feb 2024 02:47:20 GMT Reply-To: From: To: "'Junio C Hamano'" Cc: References: <000401da5c4c$fd4ad260$f7e07720$@nexbridge.com> In-Reply-To: Subject: RE: [BUG] git 2.44.0-rc0 t0080.1 Breaks on NonStop x86 and ia64 Date: Sat, 10 Feb 2024 21:47:14 -0500 Organization: Nexbridge Inc. Message-ID: <002a01da5c94$a1bc5340$e534f9c0$@nexbridge.com> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEKhykLt/LB5hLsEaYKWm4eL/p/IgHSi0nNspWF5ZA= Content-Language: en-ca On Saturday, February 10, 2024 9:06 PM, Junio C Hamano wrote: > writes: > >> The diff appears to have failed because of an assumption of how paths >> are resolved during compilation. The assumption is that files remain >> partially qualified, which is not the case in all C compilers. This is >> c99. My experience with gcc is that it qualifies names differently >> than other compilers. > >I just found this bit of gem in t/unit-tests/test-lib.c. I guess Visual C falls into the >same category as yours, while GCC and Clang are from different camps? > >The easiest way forward may be to build on top of it, perhaps like so, to generalize >the make_relative() to cover your case, too? > > t/unit-tests/test-lib.c | 63 +++++++++++++++++++++++++++++++++++++--------- >--- > 1 file changed, 48 insertions(+), 15 deletions(-) > >diff --git c/t/unit-tests/test-lib.c w/t/unit-tests/test-lib.c index >7bf9dfdb95..69dbe1bbc7 100644 >--- c/t/unit-tests/test-lib.c >+++ w/t/unit-tests/test-lib.c >@@ -21,45 +21,78 @@ static struct { > .result = RESULT_NONE, > }; > >-#ifndef _MSC_VER >-#define make_relative(location) location -#else >+#include "dir.h" > /* > * Visual C interpolates the absolute Windows path for `__FILE__`, > * but we want to see relative paths, as verified by t0080. >+ * There are other compilers that do the same, and are not for >+ * Windows. > */ >-#include "dir.h" >- > static const char *make_relative(const char *location) { > static char prefix[] = __FILE__, buf[PATH_MAX], *p; > static size_t prefix_len; >+ static int need_bs_to_fs = -1; > >- if (!prefix_len) { >+ /* one-time preparation */ >+ if (need_bs_to_fs < 0) { > size_t len = strlen(prefix); >- const char *needle = "\\t\\unit-tests\\test-lib.c"; >+ char needle[] = "t\\unit-tests\\test-lib.c"; > size_t needle_len = strlen(needle); > >- if (len < needle_len || strcmp(needle, prefix + len - needle_len)) >+ if (len < needle_len) >+ die("unexpected prefix '%s'", prefix); >+ >+ /* >+ * The path could be relative (t/unit-tests/test-lib.c) >+ * or full (/home/user/git/t/unit-tests/test-lib.c). >+ * Check the slash between "t" and "unit-tests". >+ */ >+ prefix_len = len - needle_len; >+ if (prefix[prefix_len + 1] == '/') { >+ /* Oh, we're not Windows */ >+ for (size_t i = 0; i < needle_len; i++) >+ if (needle[i] == '\\') >+ needle[i] = '/'; >+ need_bs_to_fs = 0; >+ } else { >+ need_bs_to_fs = 1; >+ } >+ >+ /* >+ * prefix_len == 0 if the compiler gives paths relative >+ * to the root of the working tree. Otherwise, we want >+ * to see that we did find the needle[] at a directory >+ * boundary. >+ */ >+ if (fspathcmp(needle, prefix + prefix_len) || >+ (prefix_len && >+ prefix[prefix_len - 1] != '/' && >+ prefix[prefix_len - 1] != '\\')) > die("unexpected suffix of '%s'", prefix); > >- /* let it end in a directory separator */ >- prefix_len = len - needle_len + 1; > } > >+ /* >+ * If our compiler gives relative paths and we do not need >+ * to munge directory separator, we can return location as-is. >+ */ >+ if (!prefix_len && !need_bs_to_fs) >+ return location; >+ > /* Does it not start with the expected prefix? */ > if (fspathncmp(location, prefix, prefix_len)) > return location; > > strlcpy(buf, location + prefix_len, sizeof(buf)); > /* convert backslashes to forward slashes */ >- for (p = buf; *p; p++) >- if (*p == '\\') >- *p = '/'; >- >+ if (need_bs_to_fs) { >+ for (p = buf; *p; p++) >+ if (*p == '\\') >+ *p = '/'; >+ } > return buf; > } >-#endif > > static void msg_with_prefix(const char *prefix, const char *format, va_list ap) { This looks like a good plan. --Randall