#1300 INITIALIZE <category> TO VALUE ignores the category, and a list of category-names is refused
INITIALIZE R ALPHANUMERIC TO VALUE resets every item of R that has a VALUE clause, whatever its category. cobc also refuses a list of category-names, ALPHANUMERIC ALPHABETIC TO VALUE or the same in REPLACING, which the general format allows. We report the two together because accepting the list needs the category check.
To reproduce
inicat.cob (attached, free format):
IDENTIFICATION DIVISION.
PROGRAM-ID. INICAT.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 R.
05 X1 PIC X(2) VALUE "AB".
05 A1 PIC A(2) VALUE "CD".
05 N1 PIC 9(2) VALUE 12.
PROCEDURE DIVISION.
PERFORM SPOIL
INITIALIZE R ALPHANUMERIC TO VALUE
DISPLAY "ALPHANUMERIC TO VALUE [" R "]"
PERFORM SPOIL
INITIALIZE R NUMERIC TO VALUE
DISPLAY "NUMERIC TO VALUE [" R "]"
PERFORM SPOIL
INITIALIZE R ALPHANUMERIC TO VALUE
THEN REPLACING NUMERIC DATA BY 7
DISPLAY "... REPLACING NUMERIC [" R "]"
STOP RUN.
SPOIL.
MOVE "zz" TO X1
MOVE "yy" TO A1
MOVE 99 TO N1.
cobc -x -free -std=cobol2014 inicat.cob && ./inicat
What happens
3.2.0 and 3.3-dev r5751 both print
ALPHANUMERIC TO VALUE [ABCD12]
NUMERIC TO VALUE [ABCD12]
... REPLACING NUMERIC [ABCD12]
inilist.cob (attached) writes ALPHANUMERIC ALPHABETIC TO VALUE and the same list in REPLACING; both versions stop with (source excerpts omitted)
inilist.cob:11: error: syntax error, unexpected ALPHABETIC, expecting VALUE
inilist.cob:14: error: syntax error, unexpected ALPHABETIC, expecting BY
The same without -std and with -std=cobol2002.
What should happen
ISO/IEC 1989:2023 14.9.20.4 general rule 5 c) 1. makes an elementary item with a VALUE clause of its own a receiving operand when "The VALUE phrase is specified, the category of the elementary data item is one of the categories specified or implied in the VALUE phrase". So inicat should print [AByy99], [zzyy12] and [AByy07], where N1 gets 7 from REPLACING (rule 6 b)). In the general format (14.9.20.2) the category-name list has choice indicators, so one or more categories may be written, in any order (5.2.6.4), and inilist should print [ABCD99] and [Q Q 99]. The same in 2002 and in the 2014 FCD.
Why it happens
In cobc/parser.y, _initialize_value and initialize_replacing_item take a single initialize_category. In cobc/codegen.c, deduce_initialize_type, output_initialize_one and the two table-format VALUES checks test only p->val && f->values, so the category held in p->val is never compared with the item's.
Proposed fix
The attached n10-initialize-category-list.patch (against 3.3-dev r5751) adds an initialize_category_list rule to parser.y for the VALUE phrase and each REPLACING item. A new initialize_to_value_p in codegen.c replaces those tests; it is true when a field has a VALUE and ALL or its category was named. ALL TO VALUE, REPLACING alone, DEFAULT and a plain INITIALIZE generate the same C as before. With the patch both programs print the results above.
A category named twice in the VALUE or REPLACING phrase is now an error (5.2.6.4 for the VALUE list; 14.9.20.3 6) for REPLACING); REPLACING NUMERIC DATA BY 1 NUMERIC DATA BY 2 compiled before. A group's own VALUE is applied for ALL or ALPHANUMERIC, as ALL TO VALUE does today, although rule 5 c) 1. b. counts only an elementary item's own VALUE. INITIALIZE OUTER (2) ALPHANUMERIC TO VALUE with table-format VALUES now also sets OUTER (1), outside identifier-1, as ALL TO VALUE already does. In a table, cobc still copies occurrence 1 to the others (propagate_table), also over items of an unnamed category, as REPLACING does today; that is a separate defect.
It adds the testsuite case "INITIALIZE with category-names" to run_initialize.at, with ChangeLog entries. make check: 1373 expected, 9 skipped, 0 failed (1372 unpatched); the new test fails without the patch.
Related
- bugs #1283: table VALUES with FROM and TO are not applied.
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.
