Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)

From: Torsten Bögershausen <tboegi@web.de>
Date: Nov 25, 2018, 08:21 UTC
Message-ID: <20181125082145.GA15747@tor.lan>
In-Reply-To: <20181125042835.GA24530@tor.lan>

On Sun, Nov 25, 2018 at 05:28:35AM +0100, Torsten Bögershausen wrote:

Show 36 quoted lines

> On Sat, Nov 24, 2018 at 08:33:37PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > 
> > On Wed, Sep 05 2018, Ævar Arnfjörð Bjarmason wrote:
> > 
> > > On Wed, Sep 05 2018, Eric Sunshine wrote:
> 
> []
> 
> > > SunCC used to be ahead of GCC & Clang when it came to certain classes of
> > > warnings, but e.g. now everything it complains about is because it
> > > doesn't understand C as well, e.g. we have quite a few compile warnings
> > > due to code like this, which it claims is unreachable (but isn't):
> > > https://github.com/git/git/blob/v2.19.0-rc2/read-cache.c#L950-L955
> > 
> 
> Wait a second - even if the compiler claims something (wrong)...
> there a still 1+1/2 questions from my side:
> 
> 
> int verify_path(const char *path, unsigned mode)
> {
> 	char c;
> 	     ^
> 	/* Q1: should  "c" be initialized like this: */
> 	char c = *path;
>         
> 	if (has_dos_drive_prefix(path))
> 		return 0;
> 
> 	goto inside;
> 	^^^^^^^^^^^^ /* Q2: and why do we need the "goto" here ? */
> 	for (;;) {
> 		if (!c)
> 			return 1;
> 		if (is_dir_sep(c)) {
> inside:

After some re-reading, I think that the "goto inside" was just hard to read....

Out of interest: would the following make the compiler happy ?

diff --git a/read-cache.c b/read-cache.c
index 49add63fe1..d574d58b9d 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -951,17 +951,15 @@ static int verify_dotfile(const char *rest, unsigned mode)
 
 int verify_path(const char *path, unsigned mode)
 {
-	char c;
+	char c = *path ? '/' : '\0';
 
 	if (has_dos_drive_prefix(path))
 		return 0;
 
-	goto inside;
 	for (;;) {
 		if (!c)
 			return 1;
 		if (is_dir_sep(c)) {
-inside:
 			if (protect_hfs) {
 				if (is_hfs_dotgit(path))
 					return 0;