On 6/2/2015 11:11 AM, Warren Young wrote:
On Jun 2, 2015, at 12:02 PM, Joerg Sonnenberger
<[email protected]> wrote:
On Tue, Jun 02, 2015 at 11:55:39AM -0600, Warren Young wrote:
On Jun 2, 2015, at 2:21 AM, Jan Nijtmans <[email protected]>
wrote:
It turns out not to be a gcc optimization bug after all: the
optimization is very valid
According to what standard?? What I see in 30af11d4 should be
legal even in C89.
It is syntactically correct, but UB.
“Undefined Behavior”?
The variable is going out of scope
The patch changes only the scope of azView, so if it is out of scope,
then the use on line 725 won’t compile.
This bothered me too, so I looked a little more closely. Jan and Joerg
are both right. The problem is that azView[] has automatic storage class
when it (actually its address) is passed in to
style_submenu_multichoice() on line 744. That function preserves a copy
of the pointer in a module-static array on line 285:
aSubmenuCtrl[nSubmenuCtrl].azChoice = azChoice;
Later, the array aSubmenuCtrl[] is enumerated in style_footer() to draw
the submenu. In 30af11d4, azView[] has gone out of scope before the call
to style_footer(), so the compiler was free to reuse its storage for
anything. The UB is caused by the live pointer to it that is preserved
in aSubmenuCtrl[].
So Jan's fix is correct, moving the scope of azView[] to encompass both
the call to style_submenu_multichoice() and style_footer() provides the
guaranteed lifetime for the storage to be valid.
This is the class of bug that the optimizer is likely to expose, and
that is difficult for tools to find. Valgrind would likely have found
it, but would have to have executed a test case that attempted to
generate the /reports page.
The only way you can refer to a variable that has gone out of scope
is to pass pointers around, which isn’t going on here.
It is what happened here, but via a static pointer in another module
holding state from one function to another.
--
Ross Berteig [email protected]
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
+1 626 351 1590 FAX
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
