#31 1.x: EVALUATE WHEN NOT binds NOT to entire statement

GC 1.x
pending
nobody
None
3
2015-04-23
2011-03-09
No

There is a problem with WHEN NOT constructs within an EVALUATE statement. The problem occurs when the WHEN statements that precedes the WHEN NOT do not have their own imperative statements. In this case the NOT is bound to the entire compound statement. (CASE 1 below : the NOT is bound to ( WTRUE AND ((XTRUE AND YTRUE) OR ZTRUE) )

If the WHEN NOT is either the only WHEN in the EVALUATE statement or is preceded by WHEN clauses that have their own imperative statement,
the NOT is bound to the 1st term in the compound statement. (CASE 2 below : the NOT is bound to WTRUE)

There are two EVALUATE STATEMENTs below. In the 1st case the "NOT" is bound to the 1st term in the WHEN clause, in the 2nd EVALUATE statement the "NOT" is bound to the entire statement. At a minimum the code being generated by the compiler is inconsistent. Other compilers such as MicroFocus and IBM always bing the "NOT" to the 1st term and not to the entire statement.

CASE-1: NOT is bound to the 1st term ( WTRUE)

           EVALUATE TRUE
              WHEN ATRUE
              WHEN NOT  WTRUE AND ((XTRUE AND YTRUE) OR   ZTRUE)
                       MOVE WHEN-SELECTED TO EVAL-RESULT
              WHEN OTHER
                       MOVE OTHER-SELECTED TO EVAL-RESULT
           END-EVALUATE

CASE-2 : The NOT is bound to the entire statement ( WTRUE AND ((XTRUE AND YTRUE) OR ZTRUE))

           EVALUATE TRUE
              WHEN NOT  WTRUE AND ((XTRUE AND YTRUE) OR   ZTRUE)
                       MOVE WHEN-SELECTED TO EVAL-RESULT
              WHEN OTHER
                       MOVE OTHER-SELECTED TO EVAL-RESULT
           END-EVALUATE

CASE 3. The NOT is bound to 1st term (WTRUE) in WHEN, the same as CASE 1.

           EVALUATE TRUE
              WHEN ATRUE
                       MOVE WHEN-ATRUE    TO EVAL-RESULT
              WHEN NOT  WTRUE AND ((XTRUE AND YTRUE) OR   ZTRUE)
                       MOVE WHEN-SELECTED TO EVAL-RESULT
              WHEN OTHER
                       MOVE OTHER-SELECTED TO EVAL-RESULT
           END-EVALUATE

The behavior that is consistent with other compilers is that the NOT is implicitly bound to the 1st term in the compound statement, not the entire statement.

CASE-1. this is the code generated in the case where the WHEN NOT is the only WHEN in the evaluate :

   /* PTPXEVAL.cbl:1043: EVALUATE */
   {
     if ((!((int)cob_cmp (&f_21, &c_31) == 0) && ((((int)cob_cmp (&f_24, &c_32) == 0) && ((int)cob_cmp (&f_27, &c_33) == 0)) || ((in        t)cob_cmp (&f_30, &c_34) == 0))))

CASE-2. this is the code generated in the case where the WHEN NOT clause has a preceding WHEN with no imperative statement of its own ( this is the where the bug is ) as you can see the ! is bound to the entire compound statement

   /* PTPXEVAL.cbl:1078: EVALUATE */
   {
     if ((((int)cob_cmp (&f_17, &c_35) == 0) || !(((int)cob_cmp (&f_21, &c_31) == 0) && ((((int)cob_cmp (&f_24, &c_32) == 0) && ((in        t)cob_cmp (&f_27, &c_33) == 0)) || (int)cob_cmp (&f_30, &c_34) == 0))))

CASE-3. in this case the WHEN NOT clause is preceded with a WHEN statement that has an imperative and the NOT is just bound to the 1st term in the compound statement

   /* PTPXEVAL.cbl:1114: EVALUATE */
   {
     if (((int)cob_cmp (&f_17, &c_35) == 0))
       {
         /* PTPXEVAL.cbl:1116: MOVE */
         {
           memcpy (b_9, b_7, 32);
         }
       }
     else
       if ((!((int)cob_cmp (&f_21, &c_31) == 0) && ((((int)cob_cmp (&f_24, &c_32) == 0) && ((int)cob_cmp (&f_27, &c_33) == 0)) || ((        int)cob_cmp (&f_30, &c_34) == 0))))
         {

Discussion

  • Scott Phillips

    Scott Phillips - 2011-03-09

    test case for EVALUATE WHEN NOT

     
  • Simon Sobisch

    Simon Sobisch - 2011-03-21

    Thank you for reporting this bug and the good analyses. The error is fixed for upcoming version 2.0.

     
  • Sergey Kashyrin

    Sergey Kashyrin - 2012-10-24

    Hi Scott,

    Can you post the test as short as possible (it's hard to get thru debug to the failing stuff) ?
    I see it works in my builds (based on May19 09 OC 1.1 - post-Feb) and after.

     
  • Simon Sobisch

    Simon Sobisch - 2014-02-26

    Fixed in 2.x (the builds of Sergey based on May19 are tagged as 1.1 but were early 2.0 sources).

    Not sure if we want to retrofix 1.x or simply see this as "known bug".

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks