Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Struct Error
Date: Fri, 24 Jan 2025 22:53:45 +0000
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <vn15lo$2ej5b$1@dont-email.me>
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>
 <20250124122425.242@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 Jan 2025 23:53:45 +0100 (CET)
Injection-Info: dont-email.me; posting-host="62e11859e1bc3fbf24e0afd8e4e14dcc";
	logging-data="2575531"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+bVYWdcrf1n9vjFQ7p0bSb"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:89KOPgPw9pKc1zF963/92ocA3gg=
Content-Language: en-GB
In-Reply-To: <20250124122425.242@kylheku.com>
Bytes: 3480

On 24/01/2025 20:31, Kaz Kylheku wrote:
> 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.

While gcc gives that one error in the complete program, g++ gives about 
250 errors.

I just excluded that program from the set of benchmarks I was testing.

The C transpiler used is a deprecated product and I'm not about to start 
messing with it now. I thought there might have been a simple tweak I 
could have made manually.