On 11/10/2022 17:18, Kaz Kylheku wrote:
> On 2022-10-11, Bart <bc@freeuk.com> wrote:
>> On 08/10/2022 18:43, Bart wrote:
>>> Can anyone explain why this isn't liked by gcc and clang:
>>>
>>>
>>>     struct tag {
>>>         int a,b,c,d;
>>>         struct tag (*e)[];
>>>     };
>>>
>>> The last member is a pointer to unbounded array of 'struct tag'.
>>>
>>> gcc complains of an incomplete type, and clang says something about the
>>> struct not being complete until the closing }.
>>>
>>> Yet, a last member of 'struct tag *e;', or even as a first member, is
>>> fine, even though the } is some way off.
>>>
>>> Neither tcc nor bcc compilers have a problem with it, and report a size
>>> of 24 bytes.
>>>
>>> Also, what is the workaround here?
>>
>> Apparently there is no workaround. However a member like this works:
>>
>> struct tag *e[5];
>>
>> So the original source was changed to use 'array 5 of pointer to struct'
>> instead of 'pointer array of struct'.
>
> That wastefully puts five pointers into your structure where you
> previously just had one. Why would you make it [5] rather than just [1]?

That's true. But in the app concerned (https://pastebin.com/EKnT2R2c),
this struct is part of a tree structure and they are only wasted at
terminal nodes.

Another possible inefficiency is in allocating 5 separate structs via
malloc instead of one block of five (although I suppose I could allocate
such a block anyway, and set the 4 trailing pointers accordingly.)

But it's an easy workaround in the original language which maps to C
code that gcc accepts.

(I'm still not sure why T*[] works in this situation, as does T*, but
not T(*).)

On 2022-10-11, Bart <bc@freeuk.com> wrote:
> On 11/10/2022 17:18, Kaz Kylheku wrote:
>> On 2022-10-11, Bart <bc@freeuk.com> wrote:
>>> On 08/10/2022 18:43, Bart wrote:
>>>> Can anyone explain why this isn't liked by gcc and clang:
>>>>
>>>>
>>>>     struct tag {
>>>>         int a,b,c,d;
>>>>         struct tag (*e)[];
>>>>     };
>>>>
>>>> The last member is a pointer to unbounded array of 'struct tag'.
>>>>
>>>> gcc complains of an incomplete type, and clang says something about the
>>>> struct not being complete until the closing }.
>>>>
>>>> Yet, a last member of 'struct tag *e;', or even as a first member, is
>>>> fine, even though the } is some way off.
>>>>
>>>> Neither tcc nor bcc compilers have a problem with it, and report a size
>>>> of 24 bytes.
>>>>
>>>> Also, what is the workaround here?
>>>
>>> Apparently there is no workaround. However a member like this works:
>>>
>>> struct tag *e[5];
>>>
>>> So the original source was changed to use 'array 5 of pointer to struct'
>>> instead of 'pointer array of struct'.
>>
>> That wastefully puts five pointers into your structure where you
>> previously just had one. Why would you make it [5] rather than just [1]?
>
> That's true. But in the app concerned (https://pastebin.com/EKnT2R2c),
> this struct is part of a tree structure and they are only wasted at
> terminal nodes.

That could be most of the tree! More than half the nodes of a balanced,
full binary tree are terminal nodes:

E.g. 3 internal, 4 leaf:

1
2 3
4 5 6 7

This gets worse with n-ary, of course.

If you don't care about space used in terminal nodes, it must be that
the tree is small, not that there are few terminal nodes compared
to internal.

> (I'm still not sure why T*[] works in this situation, as does T*, but
> not T(*).)

Because an "array of incomplete element type T" does not occur,
only a pointer to incomplete type or array thereof.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Chris M. Thomasson:

> For some reason, I like to encapsulate a fixed array in a
> struct, to make things easier, in a sense...

You are not alone, for Bryan Henderson requires this in his
style requirements for NetPbm.

--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

On 2022-10-12, Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Chris M. Thomasson:
>
>> For some reason, I like to encapsulate a fixed array in a
>> struct, to make things easier, in a sense...
>
> You are not alone, for Bryan Henderson requires this in his
> style requirements for NetPbm.

In the TXR Lisp FFI, I allow vectors of a known size to be passed by
value to C functions, and returned. The C function must declare a
struture which wraps the array.

So that is to say, if on the C side we have:

struct { int a[4] } fun(struct { int b[3] } arg);

on the Lisp side I can treat that as

(deffi fun "fun" (array 4 int) ((array 3 int)))

or:

(typedef rettype (array 4 int))
(typedef argtype (array 3 int))
(deffi fun "fun" rettype (argtype))

and just call it ias

(fun #(1 2 3))

where some return value like #(1 2 3 4) emerges.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal