Thread

1. psql use of 'volatile'

   Bruce Momjian <pgman@candle.pha.pa.us> — 2000-06-29T16:17:19Z

   Can someone explain why 'volatile' is used in psql/mainloop.c?  Seems
   volatile is only for hardware-specific variables that can not be
   optimized.
   
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     pgman@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
   
   

2. Re: psql use of 'volatile'

   Peter Eisentraut <e99re41@docs.uu.se> — 2000-06-29T16:36:48Z

   On Thu, 29 Jun 2000, Bruce Momjian wrote:
   
   > Can someone explain why 'volatile' is used in psql/mainloop.c?
   
   If you remove them then you get tons of warnings about variables possibly
   getting clobbered. The reason is the longjmp business that's going on when
   you press Control-C. (The fact that the variables would get clobbered is
   not critical since they're reinitialized immediately anyway, but who am I
   to argue with the compiler.)
   
   -- 
   Peter Eisentraut                  Sernanders väg 10:115
   peter_e@gmx.net                   75262 Uppsala
   http://yi.org/peter-e/            Sweden
   
   
   

3. Re: psql use of 'volatile'

   Bruce Momjian <pgman@candle.pha.pa.us> — 2000-06-29T16:37:21Z

   [ Charset ISO-8859-1 unsupported, converting... ]
   > On Thu, 29 Jun 2000, Bruce Momjian wrote:
   > 
   > > Can someone explain why 'volatile' is used in psql/mainloop.c?
   > 
   > If you remove them then you get tons of warnings about variables possibly
   > getting clobbered. The reason is the longjmp business that's going on when
   > you press Control-C. (The fact that the variables would get clobbered is
   > not critical since they're reinitialized immediately anyway, but who am I
   > to argue with the compiler.)
   
   Agreed.
   
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     pgman@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
   
   

4. Re: psql use of 'volatile'

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-30T01:19:58Z

   Bruce Momjian <pgman@candle.pha.pa.us> writes:
   > Can someone explain why 'volatile' is used in psql/mainloop.c?  Seems
   > volatile is only for hardware-specific variables that can not be
   > optimized.
   
   Not at all.  The ANSI C spec specifically says that you must declare
   as volatile any local variables that you need to change after a
   setjmp() call.  This prevents the compiler from putting them in
   registers, which would cause their post-longjmp values to be
   uncertain.  The exact statement is that after a longjmp,
   
          [#3] All accessible objects  have  values  as  of  the  time
          longjmp  was  called,  except  that the values of objects of
          automatic storage duration that are local  to  the  function
          containing  the invocation of the corresponding setjmp macro
          that do not  have  volatile-qualified  type  and  have  been
          changed  between  the setjmp invocation and longjmp call are
          indeterminate.
   
   The reason they're "indeterminate" is that longjmp restores all the
   machine registers to the values saved by setjmp.  So, if your local
   variable foo was allocated in a register, then foo reverts to its
   value as of the time of setjmp; but if it's in memory, it doesn't
   revert.  The behavior is really perfectly "determinate", but you
   can't safely rely on which will happen.  Unless you force foo to be
   allocated in memory, which you do by labeling it "volatile".
   
   This is sort of an abuse of the intuitive meaning of "volatile",
   but it falls right out of what the qualifier actually means to a C
   compiler, which is "keep this in memory, not in a register, and
   fetch it afresh from memory every single time the program references
   it.  No common-subexpression elimination here!"
   
   			regards, tom lane