From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) |
Cc: | jwieck(at)debis(dot)com, brook(at)trillium(dot)NMSU(dot)Edu, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] PL compile warning messages |
Date: | 1998-10-12 18:31:42 |
Message-ID: | m0zSmkx-000EBRC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 1998-10-12 18:34:54 | Re: [HACKERS] TCL/TK library glitches in configure.in |
Previous Message | Hannu Krosing | 1998-10-12 17:33:29 | Re: [HACKERS] Re: yet another problem in recent builds, GIST this time |