Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: BGB 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: References: 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: 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 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. >