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
