reftable: avoid initializing structs from structs

From: Han-Wen Nienhuys <[email protected]>

Apparently, the IBM xlc compiler doesn't like this.

Signed-off-by Han-Wen Nienhuys <[email protected]>

---
reftable: avoid initializing structs from structs

Apparently, the IBM xlc compiler doesn't like this.

Signed-off-by Han-Wen Nienhuys [email protected]

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1188%2Fhanwen%2Freftable-xlc-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1188/hanwen/reftable-xlc-v1
Pull-Request: https://github.com/git/git/pull/1188

 reftable/merged_test.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

reftable/merged_test.c +11 -11

index 24461e8a802..abd34849fca 100644
@@ -207,11 +207,11 @@ static void test_merged(void)
 		},
 	};
 
-	struct reftable_ref_record want[] = {
-		r2[0],
-		r1[1],
-		r3[0],
-		r3[1],
+	struct reftable_ref_record *want[] = {
+		&r2[0],
+		&r1[1],
+		&r3[0],
+		&r3[1],
 	};
 
 	struct reftable_ref_record *refs[] = { r1, r2, r3 };

@@ -250,7 +250,7 @@ static void test_merged(void)
 
 	EXPECT(ARRAY_SIZE(want) == len);
 	for (i = 0; i < len; i++) {
-		EXPECT(reftable_ref_record_equal(&want[i], &out[i],
+		EXPECT(reftable_ref_record_equal(want[i], &out[i],
 						 GIT_SHA1_RAWSZ));
 	}
 	for (i = 0; i < len; i++) {

@@ -345,10 +345,10 @@ static void test_merged_logs(void)
 			.value_type = REFTABLE_LOG_DELETION,
 		},
 	};
-	struct reftable_log_record want[] = {
-		r2[0],
-		r3[0],
-		r1[1],
+	struct reftable_log_record *want[] = {
+		&r2[0],
+		&r3[0],
+		&r1[1],
 	};
 
 	struct reftable_log_record *logs[] = { r1, r2, r3 };

@@ -387,7 +387,7 @@ static void test_merged_logs(void)
 
 	EXPECT(ARRAY_SIZE(want) == len);
 	for (i = 0; i < len; i++) {
-		EXPECT(reftable_log_record_equal(&want[i], &out[i],
+		EXPECT(reftable_log_record_equal(want[i], &out[i],
 						 GIT_SHA1_RAWSZ));
 	}
 

base-commit: 1ffcbaa1a5f10c9f706314d77f88de20a4a498c2

I can confirm that this works on the xlc version that errored on this before, the reftable tests even pass!

Quoted 1 line

Apparently, the IBM xlc compiler doesn't like this.

Would make sense to steal the compiler version etc. details from my <[email protected]>. I.e. eventually we'll be able to change this & other code back, as nobody will care about that older compiler version. It worked before in the pre-image on a more recent xlc.

Would make sense to steal the compiler version etc. details from my <[email protected]>. I.e. eventually we'll be able to change this & other code back, as nobody will care about that older compiler version. It worked before in the pre-image on a more recent xlc.

Quoted 5 lines · Ævar Arnfjörð Bjarmason

Would make sense to steal the compiler version etc. details from my <[email protected]>. I.e. eventually we'll be able to change this & other code back, as nobody will care about that older compiler version. It worked before in the pre-image on a more recent xlc.

If so, wouldn't it be a better option not to worry about such an old compiler at all from the get-go?

Quoted 6 lines

Quoted 5 lines

Would make sense to steal the compiler version etc. details from my <[email protected]>. I.e. eventually we'll be able to change this & other code back, as nobody will care about that older compiler version. It worked before in the pre-image on a more recent xlc.

Quoted 2 lines

If so, wouldn't it be a better option not to worry about such an old compiler at all from the get-go?

The above was a genuine question. If that "nobody will care about the old compiler" will happen only after a few years, then it may not work to just ignore the version of xlc which might still have a meaningful number of users. I just am not in a good position to judge that.

Quoted 6 lines · Junio C Hamano

Quoted 6 lines

Quoted 5 lines

Would make sense to steal the compiler version etc. details from my <[email protected]>. I.e. eventually we'll be able to change this & other code back, as nobody will care about that older compiler version. It worked before in the pre-image on a more recent xlc.

Quoted 8 lines

Quoted 2 lines

If so, wouldn't it be a better option not to worry about such an old compiler at all from the get-go?

The above was a genuine question. If that "nobody will care about the old compiler" will happen only after a few years, then it may not work to just ignore the version of xlc which might still have a meaningful number of users. I just am not in a good position to judge that.

I'm all for not worrying too much about ancient compilers, but there is no downside to this patch, so it seems fine to let this one go through.