public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/60809] New: C99 struct initialiser with embedded self assignment
@ 2014-04-10 12:37 jimis at gmx dot net
2014-04-10 14:10 ` [Bug c/60809] " jimis at gmx dot net
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: jimis at gmx dot net @ 2014-04-10 12:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/60809] C99 struct initialiser with embedded self assignment
2014-04-10 12:37 [Bug c/60809] New: C99 struct initialiser with embedded self assignment jimis at gmx dot net
@ 2014-04-10 14:10 ` jimis at gmx dot net
2014-04-10 14:24 ` schwab@linux-m68k.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: jimis at gmx dot net @ 2014-04-10 14:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/60809] C99 struct initialiser with embedded self assignment
2014-04-10 12:37 [Bug c/60809] New: C99 struct initialiser with embedded self assignment jimis at gmx dot net
2014-04-10 14:10 ` [Bug c/60809] " jimis at gmx dot net
@ 2014-04-10 14:24 ` schwab@linux-m68k.org
2014-04-10 16:33 ` jimis at gmx dot net
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: schwab@linux-m68k.org @ 2014-04-10 14:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/60809] C99 struct initialiser with embedded self assignment
2014-04-10 12:37 [Bug c/60809] New: C99 struct initialiser with embedded self assignment jimis at gmx dot net
2014-04-10 14:10 ` [Bug c/60809] " jimis at gmx dot net
2014-04-10 14:24 ` schwab@linux-m68k.org
@ 2014-04-10 16:33 ` jimis at gmx dot net
2014-04-10 18:37 ` jimis at gmx dot net
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: jimis at gmx dot net @ 2014-04-10 16:33 UTC (permalink / raw)
To: gcc-bugs
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. :-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/60809] C99 struct initialiser with embedded self assignment
2014-04-10 12:37 [Bug c/60809] New: C99 struct initialiser with embedded self assignment jimis at gmx dot net
` (2 preceding siblings ...)
2014-04-10 16:33 ` jimis at gmx dot net
@ 2014-04-10 18:37 ` jimis at gmx dot net
2014-04-29 21:43 ` joseph at codesourcery dot com
2014-04-30 5:20 ` mpolacek at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: jimis at gmx dot net @ 2014-04-10 18:37 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/60809] C99 struct initialiser with embedded self assignment
2014-04-10 12:37 [Bug c/60809] New: C99 struct initialiser with embedded self assignment jimis at gmx dot net
` (3 preceding siblings ...)
2014-04-10 18:37 ` jimis at gmx dot net
@ 2014-04-29 21:43 ` joseph at codesourcery dot com
2014-04-30 5:20 ` mpolacek at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: joseph at codesourcery dot com @ 2014-04-29 21:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/60809] C99 struct initialiser with embedded self assignment
2014-04-10 12:37 [Bug c/60809] New: C99 struct initialiser with embedded self assignment jimis at gmx dot net
` (4 preceding siblings ...)
2014-04-29 21:43 ` joseph at codesourcery dot com
@ 2014-04-30 5:20 ` mpolacek at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-04-30 5:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-04-30 5:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-10 12:37 [Bug c/60809] New: C99 struct initialiser with embedded self assignment jimis at gmx dot net
2014-04-10 14:10 ` [Bug c/60809] " jimis at gmx dot net
2014-04-10 14:24 ` schwab@linux-m68k.org
2014-04-10 16:33 ` jimis at gmx dot net
2014-04-10 18:37 ` jimis at gmx dot net
2014-04-29 21:43 ` joseph at codesourcery dot com
2014-04-30 5:20 ` mpolacek at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).