Re: Struct Error

On 23/01/2025 20:58, BGB wrote:

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 *)".

No, both of these need to know the size of the struct when accessing the i'th element:
   ....
    struct scenet *childp;
    struct scenet (*childa)[];
  };
The only thing you can't do with x->childa is perform pointer arithmetic on the whole pointer-to-array, since the array size is zero. But doing (x->childa)[i] should be fine.
As is clear since other compilers (excluding those that lavishly copy gcc's behaviour) have no problem with it.

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.

It's a 'pointer to array'; it might be uncommon in C (because of its fugly syntax), but it hs hardly obscure!

 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.

T(*)[] is a perfectly valid type; there is no reason to exclude it from struct members.
It is unambiguous in my original language, and can also be in C.

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...

Yeah. I can choose to run my compiler from source each time it is invoked; you barely notice the difference! (It adds 70-80ms.)
This cuts no ice here however.

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).

You can't cross-compile on a PC?