Re: [PATCH] reftable tests: use C syntax compatible with old xlc

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jan 13, 2022, 16:22 UTC
Message-ID: <220113.86v8yntxfb.gmgdl@evledraar.gmail.com>
In-Reply-To: <CAFQ2z_M2ZH-8RNS_zxShkdaXdO4x4Vr8EwrFo6atd0qzyy36oA@mail.gmail.com>

On Thu, Jan 13 2022, Han-Wen Nienhuys wrote:

Show 16 quoted lines

> On Thu, Jan 13, 2022 at 12:38 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> Change code added in 1ae2b8cda84 (reftable: add merged table view,
>> 2021-10-07) to be compatible with older versions of AIX's IBM xlc
>> compiler. Version V12.1 of it (on gcc111.fsffrance.org) will hard
>> error with:
>>
>>     "reftable/merged_test.c", line 211.19: 1506-196 (S) Initialization between types "char*" and "struct reftable_ref_record" is not allowed.
>>     "reftable/merged_test.c", line 212.19: 1506-196 (S) Initialization between types "unsigned long long" and "struct reftable_ref_record" is not allowed.
>>     "reftable/merged_test.c", line 213.19: 1506-196 (S) Initialization between types "enum {...}" and "struct reftable_ref_record" is not allowed.
>>     "reftable/merged_test.c", line 214.19: 1506-196 (S) Initialization between types "unsigned char*" and "struct reftable_ref_record" is not allowed.
>>     "reftable/merged_test.c", line 349.19: 1506-196 (S) Initialization between types "char*" and "struct reftable_log_record" is not allowed.
>>     "reftable/merged_test.c", line 350.19: 1506-196 (S) Initialization between types "unsigned long long" and "struct reftable_log_record" is not allowed.
>>     "reftable/merged_test.c", line 351.19: 1506-196 (S) Initialization between types "enum {...}" and "struct reftable_log_record" is not allowed.
>
> Weird. What C standard does xlc implement?

I don't know. Your guess (and searching through IBM's website) is as good as mine.

AFAICT it mostly implements the C99 semantics, but doesn't grok the interpolation of structs-within-structs

Show 7 quoted lines

>> Perhaps there's a better way to do this, but just duplicating the
>> earlier struct values declared earlier in these functions works, and
>> is probably the least bad solution.
>
> I'd rather not duplicate anything. Can't you do
>
>   struct foobar *want = { &r[0], &r[2] .. }

Maybe I'm just not understanding what you mean, but this:

        struct reftable_ref_record *want = {
                &r2[0],
                &r1[1],
                &r3[0],
                &r3[1],
        };

Gives us the predictable compiler error on gcc/clang, nevermind xlc. Turn that into:

        struct reftable_ref_record want[] = {
                &r2[0],
                &r1[1],
                &r3[0],
                &r3[1],
        };

And you can get gcc/clang to emulate what that xlc version (mis)parses that as. I.e. it takes it as a reference to the nth element in that struct.