Re: Bad CALC record kills IOC

[Marty Kraimer <mrk@aps.anl.gov>]

Tim's change will appear in the next release of 3.13.

Marty Kraimer



Tim Mooney wrote:
> 
> Andrew Johnson writes...
> 
> > > BAD:
> > >
> > > grecord(calc,"$(Ring):BXBCM:TEMPA") {
> > >         field(SCAN,"10 second")
> > >         field(CALC,"( (A&C) >> 3 ) - B")
> > > ...
> >
> > The thing which I see as significant in these differences is that Ron
> > has taken the literal "3" out of the expression and put it into the
> > input D instead.  I have been aware for some time that literals aren't
> > always accepted in CALC expressions (but some work fine -- thats the
> > wierd thing about it).  I suspect this may be the area of the problem,
> > but I'm only guessing.  It may relate to a literal with an adjacent
> > space, which matches where Rozelle's saw the error being reported.
> 
> Your exactly right.
> 
> Literals (i.e., FLOAT_PT_CONST's in postfix.c) aren't accepted in CALC
> expressions when they are preceded by a space.  This is because literals
> are parsed twice, and the second parse doesn't accept spaces.  (The first
> parse, which all expression elements undergo, does handle leading spaces.)
> 
> If the line marked below is added to postfix.c, the problem goes away.
> 
> -----excerpt from postfix.c-----------
> long postfix(pinfix,ppostfix,perror)
> .
> .
> .
>             case FLOAT_PT_CONST:
>                 if (!operand_needed){
>                     *perror = 5;
>                     return(-1);
>                 }
> 
>                 /* add constant to the expression */
>                 *ppostfix++ = pelement->code;
>                 pposthold = ppostfix;
> 
>                 pinfix-=no_bytes;
> >>>----->       while (*pinfix == ' ') *ppostfix++ = *pinfix++;
>                 while (TRUE) {
> .
> .
> .
> ---------------------------------------
> 
> Tim Mooney
> Beamline Controls & Data Acquisition
> Advanced Photon Source
> Argonne National Lab