Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Struct Error
Date: Fri, 24 Jan 2025 20:31:42 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <20250124122425.242@kylheku.com>
References: <vmr5gg$137jo$1@dont-email.me> <vms4km$19srg$1@dont-email.me>
 <vmt74h$1jac0$1@dont-email.me> <vmuaij$1qc9a$1@dont-email.me>
 <vmuo5o$1snhv$2@dont-email.me> <vmvjv1$259ng$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 Jan 2025 21:31:42 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7f33a37540ba8b226dd6885cb0d9398b";
	logging-data="2502239"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+E84EXU4YnSbFkZxBfeopSFn8Em3DbAQI="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:ZumN1QWgXWh7VDY5/I312B8cYjE=
Bytes: 3186

On 2025-01-24, David Brown <david.brown@hesbynett.no> wrote:
> 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.

It does; the implementation can issue a required diagnostic,
and keep chugging along. The behavior becomes undefined, but
the same implementation can provide its own definition:
like such that when the type is completed by the time it
matters, it's all good.

The language definition only does not allow the implementation to be
called conforming if it doesn't diagnose the usage, and doesn't allow
the program's behavior to be well-defined ISO C.

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

In this particular matter, GNU C++ accepts the code. If that happens to
be because of how ISO C++ is defined, then that carries substantial
weight. Why should C require a diagnostic in something that C++
allows to pass.  (C++, whose C-like subset is touted as a "safer C"!)

Speaking of which, Bart never responded to the workaround I found,
namely that g++ accepts his code.

I'm guessing it's too abhorrent to even think about, like inviting the
occasional blasphemer into a satanic cult.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca