On Tue, Jun 02, 2015 at 12:11:55PM -0600, 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.
>
> 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.
>
> Classic example:
>
> char* foo(void)
> {
> char azView[100];
> strcpy(azView, “this won’t turn out well”);
> return azView;
> }
>
> If that’s what’s going on here, this patch won’t fix it.
But here, if I'm not mistaken the problem was more like:
----------------------------------------------------------
char *g_foo[2] = {NULL, NULL};
char *g_bar[2] = {"hello", "world"};
void foo(char *p)
{
g_foo[0] = p[0]; // this point to "azView"
g_foo[1] = p[1]; // this point to "azView"
}
void foo2()
{
// do something with g_foo, which point to azView, which may not exist
// anymore.
}
void func(void)
{
if (<some condition>) {
char *azView[2];
azView[0] = g_bar[0];
azView[1] = g_bar[1];
foo(azView);
}
foo2(); // use g_foo which point to inexistent azView
}
--
Martin G.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
