Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Struct Error
Date: Wed, 22 Jan 2025 20:05:44 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <20250122112439.579@kylheku.com>
References: <vmr5gg$137jo$1@dont-email.me>
Injection-Date: Wed, 22 Jan 2025 21:05:44 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2c35b0c98faba819f3bd92f777297998";
	logging-data="1252980"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1//XC1X1t1cQsjcm57FGiSZ4PfffL/ViSA="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:8J8BM2MUV1XCCD92WS80uvDxy2k=
Bytes: 2893

On 2025-01-22, bart <bc@freeuk.com> wrote:
> Gcc 14.1 gives me an error compiling this code:
>
>    struct vector;
>    struct scenet;
>
>    struct vector {
>        double x;
>        double y;
>        double z;
>    };
>
>    struct scenet {
>        struct vector center;
>        double radius;
>        struct scenet (*child)[];
>    };
>
> The error is:
>
>    error: array type has incomplete element type 'struct scenet'
>     struct scenet (*child)[];
>                    ^~~~~

This looks like a bug to me. There is on reason why an
incomplete array type (a pointer to which /is/ allowed!)
should be constrained to have a complete element.

Especially given that it's going to be complete by the time
it is used (in fact by the time the declaration of struct scenet is
done).

Because the array is incomplete, and we have a pointer to it,
we cannot do arithmetic on it, like child + 1.

All we can do is dereference it, like (*child) or child[0]
to get to the array.

Then when we do child[0][i], then at that time we need the element type
to be complete.

> Is there any way to fix this, or is it not possible?

Yes!

Instead of:

  gcc example.c # fails

try:

  g++ example.c # succeeds!

I don't have gcc 14 handy anywhere, but I tried with 7.5 and 11.3,
Same results.

Given that the GCC's C++ front-end accepts it, that bolsters
the case that it should just work in the C front end.

You've remembered to keep your generator's C output C++ compatible,
right? You don't use bleeding edge ISO C features, so you should be
okay.

However, C++ has function overloading and whatnot, so there
is name mangling for some global symbols, like names of functions.

It may be a good idea in the code generator to spit out extern "C"
in the right places, to keep compatibility between modules
generated as C and those generated as C++.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca