Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Struct Error
Date: Thu, 23 Jan 2025 14:58:56 -0600
Organization: A noiseless patient Spider
Lines: 129
Message-ID: <vmuaij$1qc9a$1@dont-email.me>
References: <vmr5gg$137jo$1@dont-email.me> <vms4km$19srg$1@dont-email.me>
 <vmt74h$1jac0$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 Jan 2025 21:58:59 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ed05da2ed0996c460c38981ff62c1925";
	logging-data="1913130"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+cz7+jQSDv4dWDWcxdkvEMhLyM9P/y/S0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:uX4i3qNfts55oKqP1HsWDuIZ/a8=
In-Reply-To: <vmt74h$1jac0$1@dont-email.me>
Content-Language: en-US
Bytes: 5995

On 1/23/2025 4:54 AM, bart wrote:
> On 23/01/2025 01:05, James Kuyper wrote:
>> 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)[];
>>>     };
>>
>> 6.7.6.2p2: "The element type shall not be an incomplete or function 
>> type."
>>
>> I have many draft versions of the C standard. n2912.pdf, dated
>> 2022-06-08, says in 6.7.2.1.p3 about struct types that "... the type is
>> incomplete144) until immediately after the closing brace of the list
>> defining the content, and complete thereafter."
>>
>> Therefore, struct scenet is not a complete type until the closing brace
>> of it's declaration.
> 
> Wouldn't this also be the case here:
> 
>     struct scenet *child;
>    };
> 
> The struct is incomplete, but it still knows how to do pointer 
> arithmetic with that member. The calculation is not that different from 
> the array version (actually, the code from my compiler is identical).
> 

Difference is, in this case, "sizeof(struct scenet)" is not relevant to 
"sizeof(struct scenet *)".

Formally, with the parenthesis and array, the size of the struct is 
considered relevant (even if not strictly so), but is also unknown at 
that point.


This seems like obscure edge case territory.


Alas, if I could have my way, I might define a simplified subset which 
drops some of these sorts of edge cases (the form with parenthesis would 
simply become disallowed), but, likely, this wouldn't amount to much.

Say, for a language that is:
Mostly backwards compatible with existing C code;
Allows for a smaller and simpler compilers;
Uses some C# like rules to eliminate the need for checking for typedefs 
to parse stuff.

Though, one can't go entirely over to C# like behavior if one still 
wants to support traditional separate compilation (so one would still 
have a need for things like function prototypes, header files, and a 
traditional preprocessor).

But, then one would basically just end up with C but with people being 
confused about why things like "unsigned x;" no longer work (making it 
kinda moot).


And, most people continue to swear by GCC and Clang, unconcerned with 
their multi MLOC codebases, and the overly long time it takes to 
recompile the compiler from source...

People favoring "one compiler to rule them all" over, say, smaller and 
more specialized compilers.


But, alas, I can't seem to manage to fit a C compiler into the code 
footprint of the original Doom engine, which is a bit weak.

Say, if one wanted a C compiler with under 30 kLOC, and a binary 
(covering the entirely toolchain, *) in under around 500kB, ...

*: There can be a single binary that behaves as the entire toolchain, 
and is symlinked to the various tool names. Which name it is called as 
determining how it behaves and how it parses the command-line...


Granted, my existing compiler is a bit bigger; sadly, its code footprint 
is more on par with Quake3, and its memory footprint generally a bit 
steep (well, if one wants to run it on an FPGA board with 128MB of total 
RAM; ideally one wants to keep the memory footprint needed to compile a 
moderate size program in under around 50MB or so; which is an epic fail 
for my compiler as it is...).

And, as-is, compiling stuff takes a painfully long time on a 50MHz CPU 
(even a moderately small program might take several minutes or more).

....



>>
>> However, that sentence disappeared in n3047.pdf, dated 2022-08-04. Can
>> anyone tell me why it was removed? With it gone, I'm not sure it is
>> still considered an incomplete type.
>>
>> Ignoring for the moment the fact that it's not permitted, why do you
>> want to do that? In C code, people usually use pointers to the first
>> element of an array rather than pointers to arrays. However, it
>> sometimes is a good idea to have a pointer to an array, because that
>> makes the length of the array part of the pointer type, which can be
>> used to check the validity of the code that uses that pointer to access
>> the elements of the array. But in this case, the length of the array is
>> unspecified, so there's no such benefit.
> 
> I said the code is generated, which means the original language uses a 
> pointer-to-array at that spot.
> 
> That is safer, as you can't mistakenly index a pointer which happens to 
> be a reference to a single instance.
> 
> In any case, you should surely be able to choose a T(*)[] type over T* 
> if you want, but apparently not inside a self-referential struct.
>