Re: [PATCH v2 3/8] qnum: QNumValue type for QNum value literals

[Markus Armbruster]

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Thu, Nov 19, 2020 at 01:21:58PM -0500, Eduardo Habkost wrote:
>> On Thu, Nov 19, 2020 at 11:24:52AM +0100, Markus Armbruster wrote:
> [...]
>> > >> > > +    return qnum_from_value((QNumValue) QNUM_VAL_INT(value));
>> > 
>> > No space between between (type) and its operand, please.
>> > 
>> > Could we lift the cast into the macro somehow?
>> 
>> I think we can.  I had thought the cast in the macro would break
>> usage as static variable initializers.  I was wrong.
>
> Actually, including the cast in the macro breaks QLIT_QDICT
> initializers (which use (QLitDictEntry[]) compound literals), and
> I don't know why.
>
> Compound literals in initializers of static variables is a GCC
> extension.  I don't understand why it doesn't work inside array
> compound literals, though.
>
> Any language lawyers around?
>
> This works:
>
>   typedef struct QLit {
>       int x, y;
>   } QLit;
>   
>   typedef struct Entry {
>       int key;
>       QLit value;
>   } Entry;
>   
>   Entry e = { .key = 0, .value = (QLit) { 1,   2 } };
>
> This works:
>
>   Entry *es1 = (Entry[]) {
>       { .key = 0, .value = { 1,   2 } },
>   };
>
> But this doesn't:
>
>   Entry *es2 = (Entry[]) {
>       { .key = 0, .value = (QLit) { 1,   2 } },
>   };
>
> dict.c:16:24: error: initializer element is not constant
>    16 | Entry *es2 = (Entry[]) {
>       |                        ^
> dict.c:16:24: note: (near initialization for ‘es2’)
>
> (gcc (GCC) 10.2.1 20201005 (Red Hat 10.2.1-5))

Can't explain this offhand.

Another pecularity: a const QLitObject is for the most part not actually
const.  Evidence:

    $ size 
bld-x86/libqemu-x86_64-softmmu.fa.p/meson-generated_.._qapi_qapi-introspect.c.o
       text        data     bss     dec     hex filename
      19590      351600      48  371238   5aa26 
bld-x86/libqemu-x86_64-softmmu.fa.p/meson-generated_.._qapi_qapi-introspect.c.o

Score 5 out of 100 points.