Re: Struct Error

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