11–20 of 110 posts
Earlier quoted context omitted.
[deleted]
Just read the email.
A simple example is function argument evaluation order. If you have:
foo(bar(), baz())
A compiler is free to call these functions in either order. That means if baz relies on state mutated by bar, the program may behave differently if the compiler chooses to reorder evaluation.
Since when is 40% "nearly half". Can we change the title to something like: "40% of Debian packages might break if GCC changes the way it handles undefined behavior"
...always?
> "40% of Debian packages might break if GCC changes the way it handles undefined behavior"
A lot of them are silently broken today. That's the scary part.
Since when is 40% "nearly half". Can we change the title to something like: "40% of Debian packages might break if GCC changes the way it handles undefined behavior"
Since when is 40% "nearly half". Can we change the title to something like: "40% of Debian packages might break if GCC changes the way it handles undefined behavior"
Since when is 40% "nearly half". Can we change the title to something like: "40% of Debian packages might break if GCC changes the way it handles undefined behavior"
Earlier quoted context omitted.
Just read the email.
Actually it's still a useful question, I think. A simple example is function argument evaluation order. If you have: foo(bar(), baz()) A compiler is free to call these functions in either order. That means if baz relies on state mutated by bar, the program may behave differently if the compiler chooses to reorder evaluation.
lock_two_widgets(widget *a, widget *b) {
if (a lock);
lock(&b->lock);
} else {
lock(&b->lock);
lock(&a->lock);
}
}> I have worked on many programs, and whenever I found such a problem (typically called a "portability problem"), where the code was assuming something that the language did not guarantee, I fixed the program rather than bitching about the compiler.
Earlier quoted context omitted.
Actually it's still a useful question, I think. A simple example is function argument evaluation order. If you have: foo(bar(), baz()) A compiler is free to call these functions in either order. That means if baz relies on state mutated by bar, the program may behave differently if the compiler chooses to reorder evaluation.
A perhaps more interesting, quite realistic example: lock_two_widgets(widget *a, widget *b) { if (a lock); lock(&b->lock); } else { lock(&b->lock); lock(&a->lock); } }
Edit: Your code has undefined behavior, unless the two pointers point to the same object, which is unlikely in a realistic example.
Earlier quoted context omitted.
Actually it's still a useful question, I think. A simple example is function argument evaluation order. If you have: foo(bar(), baz()) A compiler is free to call these functions in either order. That means if baz relies on state mutated by bar, the program may behave differently if the compiler chooses to reorder evaluation.
A perhaps more interesting, quite realistic example: lock_two_widgets(widget *a, widget *b) { if (a lock); lock(&b->lock); } else { lock(&b->lock); lock(&a->lock); } }