Re: [HACKERS] PL compile warning messages

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) #

In response to

Browse pgsql-hackers by date

  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