Re: Struct Error

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.