#47 Problem with inspect statement parsing

[Denis Hugonnard]

Hi,
First of all thank you for the great job you're all doing.
I think i found a problem on the inspect statement parsing ...
This program is compiling without any error

::cobol
       IDENTIFICATION DIVISION.
       PROGRAM-ID. TESTSTUFF.
      *----------------------------------------------------------------*
       ENVIRONMENT DIVISION.
      *--------------------*
      *
       DATA DIVISION.
      *-------------*
      *
       WORKING-STORAGE SECTION.
      *-----------------------*
      *
      *
       01  W01-VARIABLES.
      *------------------*
      *
           05  W01-I                      PIC S9(04) BINARY .
           05  W01-STRING                 PIC X(32)         .
      *
       PROCEDURE DIVISION .
      *-----------------------------------------*
      *
       A00-MAINLINE.
      *------------*
      *

           INSPECT W01-STRING TALLYING W01-I FOR  .
      *
           INSPECT W01-STRING TALLYING W01-I FOR  LEADING.
      *
           GOBACK .

[Simon Sobisch]

You're right, the parser should raise an error.
The problem persists since years and still occurs in 2.x.

[Simon Sobisch]

Just found another one: missing identifier/literal for CANCEL

::cobol
            CANCEL
            DISPLAY 'Do we get here' END-DISPLAY

This was fixed in 2.0 (still persists in 1.1).

TODO: we should add test suite entries for checking missing identifier/literals for all statements.

Simon

[Edward Hart]

Attached is a fix for this bug.

As part of the bug fix, I have switched the parser from LALR to GLR. Is that OK? This fix was just what came to find first, and if people prefer, I could instead have invalid forms detected through something like check_repeated.

[Simon Sobisch]

The patch looks fine - but please let us stay at LR (at least until we merged Ron's changes with 2.1).

Thank you,
Simon

[Edward Hart]

Fixed in [r899].

[Edward Hart]

Jonathan Beit-Aharon has pointed out that GnuCOBOL rejects TALLYING CHARACTER phrases, e.g.

:::cobolfree
INSPECT s1 TALLYING n1 FOR CHARACTERS, LEADING 'ABC'

[Edward Hart]

Fixed in trunk in [r3510].

[Simon Sobisch]

Merged with [r3533].

[Brent Rector]

The last two posts here reopened this ticket for bugs #138's example, INSPECT s1 TALLYING n1 FOR CHARACTERS, LEADING 'ABC'. The ticket is closed again, but 3.2.0 and 3.3-dev r5751 still refuse that statement, and CHARACTERS followed by ALL as well. Could it be reopened? A patch is attached.

To reproduce

inspchar.cob (attached):

       IDENTIFICATION DIVISION.
       PROGRAM-ID. INSPCHAR.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  T  PIC X(8) VALUE "ABACADAE".
       01  C  PIC 99 VALUE 0.
       PROCEDURE DIVISION.
       MAIN-PARA.
           INSPECT T TALLYING C
               FOR CHARACTERS BEFORE INITIAL "C" ALL "A"
           DISPLAY C
           MOVE 0 TO C
           INSPECT T TALLYING C FOR CHARACTERS, LEADING "ABA"
           DISPLAY C
           STOP RUN.

cobc -x inspchar.cob && ./inspchar

What happens

Both versions stop with (source excerpts omitted)

inspchar.cob: in paragraph 'MAIN-PARA':
inspchar.cob:10: error: missing value between ALL/LEADING/TRAILING words
inspchar.cob:13: error: missing value between ALL/LEADING/TRAILING words

and the same with -std=cobol2014, cobol2002, cobol85, ibm and mf. The reverse gets through: allchar.cob (attached) has FOR ALL CHARACTERS, with no value after ALL, and prints 08.

What should happen

05 and 08. In the tallying-phrase (ISO/IEC 1989:2023 14.9.22.2) the CHARACTERS / ALL / LEADING choice after FOR has its own ellipsis, so the phrases may follow one another in any order. The operands are tried left to right at each position (14.9.22.4 general rule 8 a) to c)), and CHARACTERS is "an implied one character operand" (8 e)): it counts positions 1-3, before the C, and ALL "A" the A's at 5 and 7; in the second INSPECT it matches every position before LEADING is tried. The same in 2002 and in the 2014 FCD.

Why it happens

check_preceding_tallying_phrases in cobc/parser.y reports the missing value for ALL/LEADING/TRAILING after CHARACTERS, which is complete in itself, but not for CHARACTERS after ALL/LEADING/TRAILING. The 2020-03-27 change for this ticket ("allow consecutives CHARACTERS keywords") covered CHARACTERS CHARACTERS; the testsuite case "INSPECT repeated keywords" accepts that and has no case of CHARACTERS followed by ALL or LEADING.

Proposed fix

The attached n10-inspect-characters-all.patch (against 3.3-dev r5751) turns the check around, so inspchar prints 05 and 08 and allchar.cob gets the missing-value error, the patch's one new refusal.

libcob tallies one operand at a time, not in the GR 8 cycle, so with the patch FOR CHARACTERS AFTER INITIAL "D" ALL "DAE" on ABACADAE prints 02 (ISO 01). FOR ALL "BA" ALL "AB" on ABAB already prints 01 (ISO 02). That is a separate runtime issue.

The patch adds the test "INSPECT TALLYING CHARACTERS then ALL/LEADING" to run_misc.at, a FOR ALL CHARACTERS line to "INSPECT repeated keywords" in syn_misc.at, and ChangeLog entries. make check: 1373 expected, 9 skipped, 0 failed (1372 unpatched); the new and changed tests fail without the patch.

Details

GnuCOBOL 3.2.0 (Ubuntu gnucobol3 3.2-4build1) and 3.3-dev r5751 (CI snapshot 3.3-dev.138 of 2026-10-29), x86_64 Linux, both run 2026-11-04.

[Simon Sobisch]

Before I inspect any patches... please read [Hacking GnuCOBOL] (mind the LLM usage part) and [Copyright reassignment].

[Simon Sobisch]

I agree that both INSPECT provided by Brent are valid, the second should ideally get a warning "CHARACTERS without before/after consumes all source, rest ignored" or similar (and the LEADING not even be generated).

It would be good to know if this was fixed in trunk (4.x) already or if the issue is the same there...