Re: Struct Error

On 24/01/2025 01:51, bart wrote:

 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.
 

This is one of these cases where the C language /could/ have been defined to allow incomplete types to be used.  But the language definition (the standards) does not allow it.
Some C compilers do a poor job of checking C code.  Some are lax and allow things that the language does not, accepting code that breaks syntax and grammar rules or constraints, and happily generating code instead of issuing the standards-required diagnostics.  (gcc in default modes is such a compiler - you need to add appropriate flags to make it do a decent job of enforcing standard checking.)
This raises a few questions :
1. Should future C standards be modified to be more lenient in the code the accept?  Was there a good reason for these limitations, and is that reason still valid?
2. Should compilers behave this way, and accept code that can have an "obvious" interpretation despite going against the C standards?
3. Should people write (or generate) C code that relies on the non-standard behaviour of some C compilers?
Certainly some restrictions in the way C was defined were heavily influenced by the compiler technology of the day.  But others - and I suspect this case is one of them - exist because they simplify the rules.  Writing rules that are detailed enough to allow everything that could, theoretically, be supported while also excluding everything else can get very complicated.  A language standard cannot say "if the compiler is smart enough to figure this out, that's okay".  A given compiler implementation can do that if it wants, but the standards cannot.
At first glance it sounds like a good idea for compilers to be flexible in what they accept.  But the risk for that is fragmentation of the language.  The whole point of standardising a language is to avoid that - so that, to a reasonable level at least, it is possible to write code that can be compiled with a large range of C compilers.  Before C was standardised, the language had already fragmented into lots of variants.   It is /not/ a good thing that compilers accept code that requires a diagnostic, or have lots of extensions enabled by default.  You should have to explicitly enable such things with flags - instead of explicitly requesting that the compiler conforms to the standards.
For some kinds of code, it is entirely appropriate to rely on extensions or non-standard features of particular compilers.  But this should be done as an exception, when there is good reason for it.
In this particular case, there is not the slightest reason for generating something non-standard.  The correct response here is to get mildly irritated that C does not support the syntax you hoped to generate, feel smug that your own language /does/ support such a syntax, then change the code generator to produce correct standard C code.
And gcc is entirely correct here.  Other compilers that reject the incorrect code are not "slavishly copying gcc's behaviour" - they are correctly implementing the C standards.  It is compilers that accept this code, without requiring flags or other explicit "enable extension" features, that are doing a poor job of being C compilers.
(gcc often does the wrong thing by default accepting bad code without question, but in this case it is correct.)