On 9/19/19 1:47 AM, Vladimir Sementsov-Ogievskiy wrote: >> "The evaluations of the initialization list expressions are >> indeterminately sequenced with respect to one another and thus the order >> in which any side effects occur is unspecified." >> >> which does not bode well for the assignment to __auto_errp_prop.errp. >> All changes to errp would have to be within the same initializer. Maybe: >> >> #define MAKE_ERRP_SAFE() \ >> g_auto(ErrorPropagator) __auto_errp_prop = { \ >> .local_err = (__auto_errp_prop.err = errp, \ >> (errp = &__auto_errp_prop.local_err), NULL) } > > Is it guaranteed that .errp will not be initialized to NULL after evaluating > of > .local_err initializer?
Probably not. > >> >> but by the time you get that complicated, just using a statement is >> easier to read. Either two declarations (the second being an unused dummy variable declared solely for its initializer's side-effects) or a declaration and a statement are the only sane ways I can see to provide guaranteed ordering. It's hidden behind a macro, so I don't care which. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org