Re: [Qemu-devel] [PATCH v2 04/14] qlit: remove compound literals

[Markus Armbruster]

Laszlo Ersek  writes:

> On 08/31/17 10:42, Markus Armbruster wrote:
>> Marc-André Lureau  writes:
>> 
>>> Hi
>>>
>>> - Original Message -
 Marc-André Lureau  writes:

> Hi
>
> - Original Message -
>> Marc-André Lureau  writes:
>>
>>> They are not considered constant expressions in C, producing an error
>>> when compiling a const QLit.
>>
>> A const QLit?  Do you mean a non-const one?
>
> Really a const QLitObject:
>
>
> const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
>  QLIT_QNULL,
>  {}
>  }));
>
> qmp-introspect.c:17:63: error: initializer element is not constant
>   const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
> ^
> Removing the "compound literals" fixes this error.

 Does QLIT_QLIST(((const QLitObject[]) { ... } work?
>>>
>>> No. Even if I put "const" all over the place (in member, in compound type 
>>> etc).
>>>
>>> Give it a try, see if you can make it const, I am out of luck.
>> 
>> The commit message's explanation is wrong.  This isn't about const at
>> all, it's about "constant expressions", which are something else
>> entirely.
>> 
>> For what it's worth, clang is cool with the compound literals.  On
>> Fedora 26 with a minimized test case (appended):
>> 
>> $ clang -c -g -O -Wall compound-lit.c
>> $ gcc -c -g -O -Wall compound-lit.c
>> compound-lit.c:30:37: error: initializer element is not constant
>>  .value.qdict = (QLitDictEntry[]){
>>  ^
>> compound-lit.c:30:37: note: (near initialization for ‘(anonymous).value’)
>> 
>> GCC bug or not?  A search of the GCC Bugzilla finds
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713
>> 
>> Copying a few notorious language lawyers^W^W^Wtrusted advisers.
>> 
>> Even if this turns out to be a gcc bug, we'll have to work around it.
>> But the work-around needs a comment then.
>> 
>> In any case, the commit message needs fixing.
>> 
>> 
>> 
>> enum {
>> QTYPE_NONE, QTYPE_QSTRING, QTYPE_QDICT,
>> };
>> 
>> typedef struct QLitDictEntry QLitDictEntry;
>> typedef struct QLitObject QLitObject;
>> 
>> struct QLitObject {
>> int type;
>> union {
>> const char *qstr;
>> QLitDictEntry *qdict;
>> } value;
>> };
>> 
>> struct QLitDictEntry {
>> const char *key;
>> QLitObject value;
>> };
>> 
>> QLitObject qlit1 = (QLitObject){
>> .type = QTYPE_QDICT,
>> .value.qdict = (QLitDictEntry[]){
>>  { "foo", {} },
>>  {}
>> }};
>> 
>> QLitObject qlit2 = (QLitObject){
>> .type = QTYPE_QDICT,
>> .value.qdict = (QLitDictEntry[]){
>>  { "foo", (QLitObject){} },
>>  {}
>> }};
>> 
>
> (1) When discussing standards conformance, please drop the {} construct;
> it is a GNUism. Replacing it with { 0 } works in all contexts, and
> conforms to the standard. (Not trying to be pedantic here, but it does
> elicit extra warnings from my gcc command line
>
> gcc -std=c99 -pedantic -Wall -Wextra -fsyntax-only
>
>
> (2) Let's see what the standard says:
>
>   6.5.2.5 Compound literals
>   Constraints
>   3 If the compound literal occurs outside the body of a function, the
> initializer list shall consist of constant expressions.
>
> In the initialization of "qlit1", one element of the initializer list
> (namely for .value.qdict) is
>
> [1] (QLitDictEntry[]) {
>   { "foo", { 0 } },
>   { 0 }
> }
>
> Is this a constant expression?
>
>   6.6 Constant expressions
>   7 More latitude is permitted for constant expressions in initializers.
> Such a constant expression shall be, or evaluate to, one of the
> following:
> - an arithmetic constant expression,
> - a null pointer constant,
> - an address constant, or
> - an address constant for an object type plus or minus an integer
>   constant expression.
>
> Now, is [1] an address constant?
>
>   6.6 Constant expressions
>   9 An address constant is a null pointer, a pointer to an lvalue
> designating an object of static storage duration, or a pointer to a
> function designator; it shall be created explicitly using the unary
> & operator or an integer constant cast to pointer type, or
> implicitly by the use of an expression of array or function type.
> The array-subscript [] and member-access . and -> operators, the
> address & and indirection * unary operators, and pointer casts may
> be used in the creation of an address constant, but the value of an
> object shall not be accessed by use of these operators.
>
> "expression of array [...] type" applies; question is:
> - is [1] an lvalue designating an object of static storage duration?
>
>   6.5.2.5 Compound literals
>   Semantics

Re: [Qemu-devel] [PATCH v2 04/14] qlit: remove compound literals

[Laszlo Ersek]

On 08/31/17 10:42, Markus Armbruster wrote:
> Marc-André Lureau  writes:
> 
>> Hi
>>
>> - Original Message -
>>> Marc-André Lureau  writes:
>>>
 Hi

 - Original Message -
> Marc-André Lureau  writes:
>
>> They are not considered constant expressions in C, producing an error
>> when compiling a const QLit.
>
> A const QLit?  Do you mean a non-const one?

 Really a const QLitObject:


 const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
  QLIT_QNULL,
  {}
  }));

 qmp-introspect.c:17:63: error: initializer element is not constant
   const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
 ^
 Removing the "compound literals" fixes this error.
>>>
>>> Does QLIT_QLIST(((const QLitObject[]) { ... } work?
>>
>> No. Even if I put "const" all over the place (in member, in compound type 
>> etc).
>>
>> Give it a try, see if you can make it const, I am out of luck.
> 
> The commit message's explanation is wrong.  This isn't about const at
> all, it's about "constant expressions", which are something else
> entirely.
> 
> For what it's worth, clang is cool with the compound literals.  On
> Fedora 26 with a minimized test case (appended):
> 
> $ clang -c -g -O -Wall compound-lit.c
> $ gcc -c -g -O -Wall compound-lit.c
> compound-lit.c:30:37: error: initializer element is not constant
>  .value.qdict = (QLitDictEntry[]){
>  ^
> compound-lit.c:30:37: note: (near initialization for ‘(anonymous).value’)
> 
> GCC bug or not?  A search of the GCC Bugzilla finds
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713
> 
> Copying a few notorious language lawyers^W^W^Wtrusted advisers.
> 
> Even if this turns out to be a gcc bug, we'll have to work around it.
> But the work-around needs a comment then.
> 
> In any case, the commit message needs fixing.
> 
> 
> 
> enum {
> QTYPE_NONE, QTYPE_QSTRING, QTYPE_QDICT,
> };
> 
> typedef struct QLitDictEntry QLitDictEntry;
> typedef struct QLitObject QLitObject;
> 
> struct QLitObject {
> int type;
> union {
> const char *qstr;
> QLitDictEntry *qdict;
> } value;
> };
> 
> struct QLitDictEntry {
> const char *key;
> QLitObject value;
> };
> 
> QLitObject qlit1 = (QLitObject){
> .type = QTYPE_QDICT,
> .value.qdict = (QLitDictEntry[]){
>   { "foo", {} },
>   {}
> }};
> 
> QLitObject qlit2 = (QLitObject){
> .type = QTYPE_QDICT,
> .value.qdict = (QLitDictEntry[]){
>   { "foo", (QLitObject){} },
>   {}
> }};
> 

(1) When discussing standards conformance, please drop the {} construct;
it is a GNUism. Replacing it with { 0 } works in all contexts, and
conforms to the standard. (Not trying to be pedantic here, but it does
elicit extra warnings from my gcc command line

gcc -std=c99 -pedantic -Wall -Wextra -fsyntax-only


(2) Let's see what the standard says:

  6.5.2.5 Compound literals
  Constraints
  3 If the compound literal occurs outside the body of a function, the
initializer list shall consist of constant expressions.

In the initialization of "qlit1", one element of the initializer list
(namely for .value.qdict) is

[1] (QLitDictEntry[]) {
  { "foo", { 0 } },
  { 0 }
}

Is this a constant expression?

  6.6 Constant expressions
  7 More latitude is permitted for constant expressions in initializers.
Such a constant expression shall be, or evaluate to, one of the
following:
- an arithmetic constant expression,
- a null pointer constant,
- an address constant, or
- an address constant for an object type plus or minus an integer
  constant expression.

Now, is [1] an address constant?

  6.6 Constant expressions
  9 An address constant is a null pointer, a pointer to an lvalue
designating an object of static storage duration, or a pointer to a
function designator; it shall be created explicitly using the unary
& operator or an integer constant cast to pointer type, or
implicitly by the use of an expression of array or function type.
The array-subscript [] and member-access . and -> operators, the
address & and indirection * unary operators, and pointer casts may
be used in the creation of an address constant, but the value of an
object shall not be accessed by use of these operators.

"expression of array [...] type" applies; question is:
- is [1] an lvalue designating an object of static storage duration?

  6.5.2.5 Compound literals
  Semantics
  5 If the type name specifies an array of unknown size, the size is
determined by the initializer list as specified in 6.7.8, and the
type of the compound literal is that of the completed array type.
Otherwise (when the 

Re: [Qemu-devel] [PATCH v2 04/14] qlit: remove compound literals

[Markus Armbruster]

Marc-André Lureau  writes:

> Hi
>
> On Thu, Aug 31, 2017 at 10:43 AM Markus Armbruster 
> wrote:
>
>> Marc-André Lureau  writes:
>>
>> > Hi
>> >
>> > - Original Message -
>> >> Marc-André Lureau  writes:
>> >>
>> >> > Hi
>> >> >
>> >> > - Original Message -
>> >> >> Marc-André Lureau  writes:
>> >> >>
>> >> >> > They are not considered constant expressions in C, producing an
>> error
>> >> >> > when compiling a const QLit.
>> >> >>
>> >> >> A const QLit?  Do you mean a non-const one?
>> >> >
>> >> > Really a const QLitObject:
>> >> >
>> >> >
>> >> > const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
>> >> >  QLIT_QNULL,
>> >> >  {}
>> >> >  }));
>> >> >
>> >> > qmp-introspect.c:17:63: error: initializer element is not constant
>> >> >   const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
>> >> > ^
>> >> > Removing the "compound literals" fixes this error.
>> >>
>> >> Does QLIT_QLIST(((const QLitObject[]) { ... } work?
>> >
>> > No. Even if I put "const" all over the place (in member, in compound
>> type etc).
>> >
>> > Give it a try, see if you can make it const, I am out of luck.
>>
>> The commit message's explanation is wrong.  This isn't about const at
>> all, it's about "constant expressions", which are something else
>> entirely.
>>
>
> The point was that declaring a non const QLit with those "compound
> literals" worked vs with const.

The keyword const is a red herring here, and that's precisely what's
wrong with the commit message.  The minimized test case demonstrates the
problem without const.

>> For what it's worth, clang is cool with the compound literals.  On
>> Fedora 26 with a minimized test case (appended):
>>
>> $ clang -c -g -O -Wall compound-lit.c
>> $ gcc -c -g -O -Wall compound-lit.c
>> compound-lit.c:30:37: error: initializer element is not constant
>>  .value.qdict = (QLitDictEntry[]){
>>  ^
>> compound-lit.c:30:37: note: (near initialization for
>> ‘(anonymous).value’)
>>
>> GCC bug or not?  A search of the GCC Bugzilla finds
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713
>>
>> Copying a few notorious language lawyers^W^W^Wtrusted advisers.
>>
>> Even if this turns out to be a gcc bug, we'll have to work around it.
>> But the work-around needs a comment then.
>>
>> In any case, the commit message needs fixing.
>>
>
> What about adapting the bug comment:
>
> qlit: remove compound literals
>
> A compound literal (i.e., "(struct Str1){1}"), is not a constant
> expression, and so it cannot be used to initialize an object with static
> storage duration.

That's better.

It's weird that a compound literal isn't a constant expression, but
arguing about it here won't make gcc treat it as one.

> $ gcc -c -g -O -Wall compound-lit.c
> compound-lit.c:30:37: error: initializer element is not constant
>  .value.qdict = (QLitDictEntry[]){
>  ^
> compound-lit.c:30:37: note: (near initialization for
> ‘(anonymous).value’)
>
> clang accepts it. In some cases, gcc accepts compound literals as
> initializer, but not in this nested case. There is a gcc bug about it:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713.
>
> Feel free to adapt on commit

Using this:

qlit: Change compound literals to initializers

The QLIT_QFOO() macros expand into compound literals.  Sadly, gcc
doesn't recognizes these as constant expressions (clang does), which
makes the macros useless for initializing objects with static storage
duration.

There is a gcc bug about it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713

Change the macros to expand into initializers.

Avoids passing judgement on "bug or no bug", and avoids referring to the
compount-lit.c example without actually including it.

I might still add a comment.

Re: [Qemu-devel] [PATCH v2 04/14] qlit: remove compound literals

[Marc-André Lureau]

Hi

On Thu, Aug 31, 2017 at 10:43 AM Markus Armbruster 
wrote:

> Marc-André Lureau  writes:
>
> > Hi
> >
> > - Original Message -
> >> Marc-André Lureau  writes:
> >>
> >> > Hi
> >> >
> >> > - Original Message -
> >> >> Marc-André Lureau  writes:
> >> >>
> >> >> > They are not considered constant expressions in C, producing an
> error
> >> >> > when compiling a const QLit.
> >> >>
> >> >> A const QLit?  Do you mean a non-const one?
> >> >
> >> > Really a const QLitObject:
> >> >
> >> >
> >> > const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
> >> >  QLIT_QNULL,
> >> >  {}
> >> >  }));
> >> >
> >> > qmp-introspect.c:17:63: error: initializer element is not constant
> >> >   const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
> >> > ^
> >> > Removing the "compound literals" fixes this error.
> >>
> >> Does QLIT_QLIST(((const QLitObject[]) { ... } work?
> >
> > No. Even if I put "const" all over the place (in member, in compound
> type etc).
> >
> > Give it a try, see if you can make it const, I am out of luck.
>
> The commit message's explanation is wrong.  This isn't about const at
> all, it's about "constant expressions", which are something else
> entirely.
>

The point was that declaring a non const QLit with those "compound
literals" worked vs with const.


> For what it's worth, clang is cool with the compound literals.  On
> Fedora 26 with a minimized test case (appended):
>
> $ clang -c -g -O -Wall compound-lit.c
> $ gcc -c -g -O -Wall compound-lit.c
> compound-lit.c:30:37: error: initializer element is not constant
>  .value.qdict = (QLitDictEntry[]){
>  ^
> compound-lit.c:30:37: note: (near initialization for
> ‘(anonymous).value’)
>
> GCC bug or not?  A search of the GCC Bugzilla finds
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713
>
> Copying a few notorious language lawyers^W^W^Wtrusted advisers.
>
> Even if this turns out to be a gcc bug, we'll have to work around it.
> But the work-around needs a comment then.
>
> In any case, the commit message needs fixing.
>

What about adapting the bug comment:

qlit: remove compound literals

A compound literal (i.e., "(struct Str1){1}"), is not a constant
expression, and so it cannot be used to initialize an object with static
storage duration.

$ gcc -c -g -O -Wall compound-lit.c
compound-lit.c:30:37: error: initializer element is not constant
 .value.qdict = (QLitDictEntry[]){
 ^
compound-lit.c:30:37: note: (near initialization for
‘(anonymous).value’)

clang accepts it. In some cases, gcc accepts compound literals as
initializer, but not in this nested case. There is a gcc bug about it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713.

Feel free to adapt on commit

thanks


>
>
> enum {
> QTYPE_NONE, QTYPE_QSTRING, QTYPE_QDICT,
> };
>
> typedef struct QLitDictEntry QLitDictEntry;
> typedef struct QLitObject QLitObject;
>
> struct QLitObject {
> int type;
> union {
> const char *qstr;
> QLitDictEntry *qdict;
> } value;
> };
>
> struct QLitDictEntry {
> const char *key;
> QLitObject value;
> };
>
> QLitObject qlit1 = (QLitObject){
> .type = QTYPE_QDICT,
> .value.qdict = (QLitDictEntry[]){
> { "foo", {} },
> {}
> }};
>
> QLitObject qlit2 = (QLitObject){
> .type = QTYPE_QDICT,
> .value.qdict = (QLitDictEntry[]){
> { "foo", (QLitObject){} },
> {}
> }};
>
> --
Marc-André Lureau

Re: [Qemu-devel] [PATCH v2 04/14] qlit: remove compound literals

[Markus Armbruster]

Marc-André Lureau  writes:

> Hi
>
> - Original Message -
>> Marc-André Lureau  writes:
>> 
>> > Hi
>> >
>> > - Original Message -
>> >> Marc-André Lureau  writes:
>> >> 
>> >> > They are not considered constant expressions in C, producing an error
>> >> > when compiling a const QLit.
>> >> 
>> >> A const QLit?  Do you mean a non-const one?
>> >
>> > Really a const QLitObject:
>> >
>> >
>> > const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
>> >  QLIT_QNULL,
>> >  {}
>> >  }));
>> >
>> > qmp-introspect.c:17:63: error: initializer element is not constant
>> >   const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
>> > ^
>> > Removing the "compound literals" fixes this error.
>> 
>> Does QLIT_QLIST(((const QLitObject[]) { ... } work?
>
> No. Even if I put "const" all over the place (in member, in compound type 
> etc).
>
> Give it a try, see if you can make it const, I am out of luck.

The commit message's explanation is wrong.  This isn't about const at
all, it's about "constant expressions", which are something else
entirely.

For what it's worth, clang is cool with the compound literals.  On
Fedora 26 with a minimized test case (appended):

$ clang -c -g -O -Wall compound-lit.c
$ gcc -c -g -O -Wall compound-lit.c
compound-lit.c:30:37: error: initializer element is not constant
 .value.qdict = (QLitDictEntry[]){
 ^
compound-lit.c:30:37: note: (near initialization for ‘(anonymous).value’)

GCC bug or not?  A search of the GCC Bugzilla finds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71713

Copying a few notorious language lawyers^W^W^Wtrusted advisers.

Even if this turns out to be a gcc bug, we'll have to work around it.
But the work-around needs a comment then.

In any case, the commit message needs fixing.



enum {
QTYPE_NONE, QTYPE_QSTRING, QTYPE_QDICT,
};

typedef struct QLitDictEntry QLitDictEntry;
typedef struct QLitObject QLitObject;

struct QLitObject {
int type;
union {
const char *qstr;
QLitDictEntry *qdict;
} value;
};

struct QLitDictEntry {
const char *key;
QLitObject value;
};

QLitObject qlit1 = (QLitObject){
.type = QTYPE_QDICT,
.value.qdict = (QLitDictEntry[]){
{ "foo", {} },
{}
}};

QLitObject qlit2 = (QLitObject){
.type = QTYPE_QDICT,
.value.qdict = (QLitDictEntry[]){
{ "foo", (QLitObject){} },
{}
}};

Re: [Qemu-devel] [PATCH v2 04/14] qlit: remove compound literals

[Marc-André Lureau]

Hi

- Original Message -
> Marc-André Lureau  writes:
> 
> > Hi
> >
> > - Original Message -
> >> Marc-André Lureau  writes:
> >> 
> >> > They are not considered constant expressions in C, producing an error
> >> > when compiling a const QLit.
> >> 
> >> A const QLit?  Do you mean a non-const one?
> >
> > Really a const QLitObject:
> >
> >
> > const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
> >  QLIT_QNULL,
> >  {}
> >  }));
> >
> > qmp-introspect.c:17:63: error: initializer element is not constant
> >   const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
> > ^
> > Removing the "compound literals" fixes this error.
> 
> Does QLIT_QLIST(((const QLitObject[]) { ... } work?

No. Even if I put "const" all over the place (in member, in compound type etc).

Give it a try, see if you can make it const, I am out of luck.

Re: [Qemu-devel] [PATCH v2 04/14] qlit: remove compound literals

[Markus Armbruster]

Marc-André Lureau  writes:

> Hi
>
> - Original Message -
>> Marc-André Lureau  writes:
>> 
>> > They are not considered constant expressions in C, producing an error
>> > when compiling a const QLit.
>> 
>> A const QLit?  Do you mean a non-const one?
>
> Really a const QLitObject:
>
>
> const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
>  QLIT_QNULL,
>  {}
>  }));
>
> qmp-introspect.c:17:63: error: initializer element is not constant
>   const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
> ^
> Removing the "compound literals" fixes this error.

Does QLIT_QLIST(((const QLitObject[]) { ... } work?

> We may want to include it in the commit message, but I think it lacks a bit 
> of "C standard" explanation. I think it is something like "compound literals" 
> are not const. But then why does it work with (QLitObject[]) ? :)

Re: [Qemu-devel] [PATCH v2 04/14] qlit: remove compound literals

[Marc-André Lureau]

Hi

- Original Message -
> Marc-André Lureau  writes:
> 
> > They are not considered constant expressions in C, producing an error
> > when compiling a const QLit.
> 
> A const QLit?  Do you mean a non-const one?

Really a const QLitObject:


const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
 QLIT_QNULL,
 {}
 }));

qmp-introspect.c:17:63: error: initializer element is not constant
  const QLitObject qmp_schema_qlit = QLIT_QLIST(((QLitObject[]) {
^
Removing the "compound literals" fixes this error.

We may want to include it in the commit message, but I think it lacks a bit of 
"C standard" explanation. I think it is something like "compound literals" are 
not const. But then why does it work with (QLitObject[]) ? :)


> 
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  include/qapi/qmp/qlit.h | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/qapi/qmp/qlit.h b/include/qapi/qmp/qlit.h
> > index a4ad91321b..f1d6eed317 100644
> > --- a/include/qapi/qmp/qlit.h
> > +++ b/include/qapi/qmp/qlit.h
> > @@ -36,13 +36,13 @@ struct QLitDictEntry {
> >  };
> >  
> >  #define QLIT_QNUM(val) \
> > -(QLitObject){.type = QTYPE_QNUM, .value.qnum = (val)}
> > +{ .type = QTYPE_QNUM, .value.qnum = (val) }
> >  #define QLIT_QSTR(val) \
> > -(QLitObject){.type = QTYPE_QSTRING, .value.qstr = (val)}
> > +{ .type = QTYPE_QSTRING, .value.qstr = (val) }
> >  #define QLIT_QDICT(val) \
> > -(QLitObject){.type = QTYPE_QDICT, .value.qdict = (val)}
> > +{ .type = QTYPE_QDICT, .value.qdict = (val) }
> >  #define QLIT_QLIST(val) \
> > -(QLitObject){.type = QTYPE_QLIST, .value.qlist = (val)}
> > +{ .type = QTYPE_QLIST, .value.qlist = (val) }
> >  
> >  int compare_litqobj_to_qobj(QLitObject *lhs, QObject *rhs);
> 

Re: [Qemu-devel] [PATCH v2 04/14] qlit: remove compound literals

[Markus Armbruster]

Marc-André Lureau  writes:

> They are not considered constant expressions in C, producing an error
> when compiling a const QLit.

A const QLit?  Do you mean a non-const one?

> Signed-off-by: Marc-André Lureau 
> ---
>  include/qapi/qmp/qlit.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/qapi/qmp/qlit.h b/include/qapi/qmp/qlit.h
> index a4ad91321b..f1d6eed317 100644
> --- a/include/qapi/qmp/qlit.h
> +++ b/include/qapi/qmp/qlit.h
> @@ -36,13 +36,13 @@ struct QLitDictEntry {
>  };
>  
>  #define QLIT_QNUM(val) \
> -(QLitObject){.type = QTYPE_QNUM, .value.qnum = (val)}
> +{ .type = QTYPE_QNUM, .value.qnum = (val) }
>  #define QLIT_QSTR(val) \
> -(QLitObject){.type = QTYPE_QSTRING, .value.qstr = (val)}
> +{ .type = QTYPE_QSTRING, .value.qstr = (val) }
>  #define QLIT_QDICT(val) \
> -(QLitObject){.type = QTYPE_QDICT, .value.qdict = (val)}
> +{ .type = QTYPE_QDICT, .value.qdict = (val) }
>  #define QLIT_QLIST(val) \
> -(QLitObject){.type = QTYPE_QLIST, .value.qlist = (val)}
> +{ .type = QTYPE_QLIST, .value.qlist = (val) }
>  
>  int compare_litqobj_to_qobj(QLitObject *lhs, QObject *rhs);