Обсуждение: PL compile warning messages

With the new PL code in pl/tcl I am getting a bunch of warnings like
the following:

    pltcl.c:443: warning: variable `prodesc' might be clobbered by `longjmp' or `vfork'

I have never seen this before in any of my programming.  What do they
mean?  Is anyone else seeing these?  Does it matter?

Cheers,
Brook

>
> With the new PL code in pl/tcl I am getting a bunch of warnings like
> the following:
>
>    pltcl.c:443: warning: variable `prodesc' might be clobbered by `longjmp' or `vfork'
>
> I have never seen this before in any of my programming.  What do they
> mean?  Is anyone else seeing these?  Does it matter?
>
> Cheers,
> Brook
>
>

    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 :-).

    Since  PL/Tcl  is  designed  to  be used as trigger language,
    raising errors with elog would be  a  normal  operation  from
    inside of PL/Tcl.

    Nothing I tested so far is really broken. I assume it doesn't
    really matter.


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

>     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.


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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