[Bug c/60809] New: C99 struct initialiser with embedded self assignment

[Bug c/60809] New: C99 struct initialiser with embedded self assignment

[jimis at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809

            Bug ID: 60809
           Summary: C99 struct initialiser with embedded self assignment
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jimis at gmx dot net

For the following code, which was a typo from my side (full example attached):

<pre>
        struct addrinfo query2 = {
                .ai_family = AF_UNSPEC,
                .ai_socktype = SOCK_STREAM,
                query2.ai_flags = AI_PASSIVE
        };
</pre>

1. A warning would be nice, something like "suggest parentheses around
assignment"
2. What is the C99 mandated behaviour? I'm not sure GCC is behaving properly.
Currently it sets ai_protocol to 1 because it is the next field after
ai_socktype. But it also sets ai_flags to 1, which I'd expect to be 0 after the
outer struct initialiser is executed.


See discussion, full example program and output, at
http://gcc.gnu.org/ml/gcc-help/2014-04/msg00033.html

[Bug c/60809] C99 struct initialiser with embedded self assignment

[jimis at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809

--- Comment #2 from jimis <jimis at gmx dot net> ---
(In reply to Marek Polacek from comment #1)
> I see nothing surprising here; an assignment expression has the value of the
> left operand after the assignment.  So we 1) set query2.ai_flags to
> AI_PASSIVE, 2) use this value to initialize .ai_protocol.

if the outer assignment runs last, shouldn't it overwrite the inner assignment?
Then it should be equivalent to that:

<pre>
        struct addrinfo query3 = {
                .ai_family = AF_UNSPEC,
                .ai_socktype = SOCK_STREAM,
        1
</pre>

Which means that ai_flags should be 0.

[Bug c/60809] C99 struct initialiser with embedded self assignment

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
6.7.9 Initialization
23 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.

[Bug c/60809] C99 struct initialiser with embedded self assignment

[jimis at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809

--- Comment #4 from jimis <jimis at gmx dot net> ---
Thanks Andreas, that's the reference I was looking for!

I guess since this code triggers unspecified behaviour, a warning would be even
more needed. :-)

[Bug c/60809] C99 struct initialiser with embedded self assignment

[jimis at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809

--- Comment #5 from jimis <jimis at gmx dot net> ---
Andreas: On a second thought, this paragraph only talks about the order
*within* the initialisation list. But no matter of that order, the
initialisation list is always evaluated to:

        {
                .ai_family = AF_UNSPEC,
                .ai_socktype = SOCK_STREAM,
                AI_PASSIVE
        };


The outer assignment to query2, should never set ai_flags, no matter what the
side-effects of the inner assignments are. Am I thinking right?

[Bug c/60809] C99 struct initialiser with embedded self assignment

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I see nothing that says anything about the sequencing of side effects in 
initialization expressions with respect to the actual initialization 
itself, or parts thereof - either to require a particular sequencing, or 
to make it indeterminately sequenced or unsequenced.  That may mean it's 
implicitly unsequenced, but I'd suggest raising this with WG14.

[Bug c/60809] C99 struct initialiser with embedded self assignment

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |SUSPENDED
   Last reconfirmed|                            |2014-04-30
     Ever confirmed|0                           |1

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #6)
> I see nothing that says anything about the sequencing of side effects in 
> initialization expressions with respect to the actual initialization 
> itself, or parts thereof - either to require a particular sequencing, or 
> to make it indeterminately sequenced or unsequenced.  That may mean it's 
> implicitly unsequenced, but I'd suggest raising this with WG14.

Thanks, I'll try to report it then; suspending for now.