On Tue, Jan 29, 2019 at 01:22:19PM +0000, Daniel P. Berrangé wrote:
> On Tue, Jan 29, 2019 at 02:12:03PM +0100, Jakub Jelinek wrote:
> > On Tue, Jan 29, 2019 at 01:04:25PM +0000, Daniel P. Berrangé wrote:
> > > The variable was already initialized right at the start. The compound
> > > literal is just a short-hand for later changing the values in several
> > > fields of the struct at once. This is no different to manually assigning
> > > new values to each individual field one at a time. eg
> > >
> > > struct demo demo = {0};
> > >
> > > ...some code with a goto...
> > >
> > > demo = (struct demo) { .cmd = "foo" };
> >
> > No, I wasn't talking about the demo variable, the warning is not about demo
> > variable. The warning is about the compound literal variable.
> > That is an anonymous (when used at block scope automatic) variable, kind
> > like:
> > struct demo __complit = { .cmd = "foo" };
> > demo = __complit;
> > and with the goto you are crossing initialization of that variable.
>
> Urgh. I would never have understood that from the warning message :-( It
> is complaining about something that doesn't even exist as far as I was
> concerned
>
> > When you aren't taking address of this, the optimizers will likely optimize
> > the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" }
> > that address could be used later on in the function, dereferenced etc.
>
> Is it practical to get the warning supressed when code is not taking the
> address of the anonymous var ?
>
> If not then we pretty much have to abandon use of these anonymous
> compound initializers for re-assigning existing variables :-(
Let me second that. In systemd upstream we have been slowly changing
code to use compound initializers instead in places where "all" fields
of a structure would be assigned. With explicit list it's easy to miss
some fields when the code is changed, and compound initialization
avoids this risk. It's much more elegant.
Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
