Bruce wrote:
>
> > I get them too and don't know exactly what they mean. I think
> > gcc is just telling that after returning to the setjmp
> > location via longjmp the variable might not contain what
> > there was before (the longjmp mechanism only restores the
> > stack pointers, not the variable contents on the stack).
> >
> > But the longjmp's are there only to clean up the Tcl's
> > interpreter nesting and allocations in the case of an
> > elog(ERROR) before really jumping back into the postgres main
> > loop. Tcl doesn't allocate via palloc, so there would be
> > memory allocations never free'd otherwise. The mentioned
> > variables aren't accessed after the longjumping session began
> > (it's really a longjmp party if Tcl triggers use in turn Tcl
> > functions where the queries invoke other functions/triggers
> > and so on :-).
>
> See postgres.c. We used to have that warning in postgres.c, but someone
> changed something to fix it. I can't see what was changed, now that I
> am looking at it.
I took a lood at it and didn't saw the changes either. Then I
played around with the code.
In some cases only a strange workaround could prevent that
warning. Creating another variable of the same type and
somewhere in the function doing var2 = var1; and then using
var2 instead (doesn't do anything useful and makes the code
more obscure).
From the gcc manpage:
-W Print extra warning messages for these events:
· A nonvolatile automatic variable might be changed
by a call to longjmp. These warnings are possible
only in optimizing compilation.
The compiler sees only the calls to setjmp. It
cannot know where longjmp will be called; in fact,
a signal handler could call it at any point in the
code. As a result, you may get a warning even when
there is in fact no problem because longjmp cannot
in fact be called at the place which would cause a
problem.
In fact I think it's legal to ignore these warnings because
there is in fact no place which would cause a problem.
And in fact I love this snippet of the manpage :-)
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #