#321 expression check is borked

[Simon Sobisch]

The following results in "Error: Invalid expression"

::cobol
       77 my pic x.

           if my
              display 'borked'
           end-if 

this is correct (a more specific error message would be nice).
But the following doesn't raise any error:

::cobol
       77 my pic x.

           if (my = 'X') AND my
              display 'borked'
           end-if

If I read the standard correctly this is wrong, the only options where an identifier can be used directly are:

• the identifier is a level-88 item
• the identifier is of class boolean and has a length of 1: PIC 1 (while this picture isn't implemented - see [feature-requests:#172] - the class is, therefore it should be possible to add this check [the testsuite entry would be XFAIL(true)]).

If this is an extension it needs a CB_CONFIG_SUPPORT with a clear description what it actually does.

Assigned to Ed in the hope he finds the time to investigate it (@Ed, you're free to opt-out)

[Vincent (Bryan) Coen]

Just seen this and I am a little puzzled,

Your have a 77 level var (which is the same as say an 01) as a subject
of a IF test but there is nothing to test for as the var is not
associated with value or more importantly a condition (88 level )

Why are you expecting it to be accepted by the compiler ?

Now if you added a 88 level to the 77 called fred then changed the tes to :

if fred
display my.

it will work.

Vince

[Simon Sobisch]

No need to be puzzled here. I don't expect the compiler to accept this - but it does (for the second sample)!

(this is a bug report)

If this is some extension I don't know about it should be documented and only be activated if requested as in all other cases it is a coding bug.

BTW: this bug (or extension) is in since years.

[Edward Hart]

I have finally found time to investigate this bug.

GnuCOBOL is interpreting the condition (my = 'X') AND my as the abbreviated condition my = 'X' AND my. I'll figure out a way to indicate to the expression builder that the abbreviated condition should be ended after a ) after a condition subject.

[Simon Sobisch]

Thank you, this would be very good.

[Edward Hart]

Fixed in [r1347].

[Simon Sobisch]

This change is identified to be the root of the last "show stoping" 2.2 problem as it leads to the following correct expression to be reported as invalid: if var > (1 + 1).

Complete test case:

::cobol
           if  var = 83  and >  1 + 1    *> valid
              continue
           end-if
           if  var = 83  and >  2        *> valid
              continue
           end-if
           if  var = 83  and > (1 + 1)   *> valid
              continue
           end-if
           if  var = 83  and var         *> valid
              continue
           if (var = 83) and var         *> invalid
              continue
           end-if

@Ed: do you see any option of fixing this today or do we need to revert it and postpone the change to 2.3?

[Simon Sobisch]

Note: All expression checks in the testsuite that contain foldable constants like 1 + 1 should be compiled with and without -fno-constant-folding to verify that these work identical.

[Simon Sobisch]

I'm reverting the part that was done for fixing this in [r1347] as we actually have a check in run_extensions.at "semi-parenthesized condition" that seems to expect something like this. I've added the previous failing "if var >= b or < (5 - 6)" to the tests.

[Edward Hart]

I'm fine with reverting the "fix" part of [r1347]. The actual bug is that cb_expr_shift removes the parentheses around any completely parsed subcondition. Without the parentheses, the parser thinks it can allow abbreviated relations after that subcondition. I might be able to fix this tonight, if I can find where abbreviated conditions are expanded.

[Edward Hart]

Should be fixed in [r1802].

[Simon Sobisch]

Thank you!