When there is codethat changes the setting of a condition inside an ‘IF’ statement that tests the condition,
and later on the same condition is tested again, the last test leads to a false-positive on S2583.
See the example below, where the value of ‘OK’ eventually evaluates to false, where the analyzer says it always evaluates to true.
Versions used:
Cobol: AcuCobol version 10.2.1, fixed format
SonarQube: Enterprise Edition Version 9.6.1 (build 59531)
Source code example:
IDENTIFICATION DIVISION.
PROGRAM-ID. PP0040.
WORKING-STORAGE SECTION.
01 FILLER PIC X(01).
88 FIRST-CONDITION VALUE "Y" FALSE "N".
01 FILLER PIC X(01).
88 SECOND-CONDITION VALUE "Y" FALSE "N".
01 FILLER PIC X(01).
88 OK VALUE "Y" FALSE "N".
PROCEDURE DIVISION.
MAIN SECTION.
SET FIRST-CONDITION TO TRUE
SET SECOND-CONDITION TO TRUE
IF FIRST-CONDITION
SET OK TO TRUE
ELSE
SET OK TO FALSE
END-IF
IF OK
IF SECOND-CONDITION
SET OK TO FALSE
END-IF
IF OK
PERFORM DO-SOMETHING
END-IF
END-IF
GOBACK
.
DO-SOMETHING SECTION.
.
I have read issue SONARCOBOL-1673, and I am afraid your description is somewhat simplifying the problem.
The condition that is tested twice can be changed by a number of things:
It could be changed directly (like you suggest)
If the condition is an 88-level of a named field, the field value could be changed, thereby
changing the condition’s value…
If any other section is PERFORM-ed between the 2 tests, the condition could be changed there.
If the condition is in the linkage item of a called program, the condition could even be changed
by another program, when that other program is called between the 2 tests.
So maybe it is a good idea to make the desciption of the issue somewhat broader, to prevent the
issue being partially solved (and thereby harder to find/reproduce in the future).
With kind regards,
Jos Abrahams
PS: I have a stupid question: Is your first name Pierre-Yves or is it Nicolas?
I believe that we handle that case correctly. No issue is raised on the following code:
ID DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 NUM1 PIC 9.
01 X PIC X.
88 COND1 VALUE "Y" FALSE "N".
PROCEDURE DIVISION.
IF COND1
IF NUM1 = 0
MOVE "N" TO X
END-IF
IF COND1
DISPLAY "..."
END-IF
END-IF.
I believe we don’t raise any issue in such a case, even when the PERFORM-ed section has no relation with the condition (which means we have false negatives).
I’m not sure I see what you mean.
Could you provide an example?
We don’t do cross-program analysis but we definitely want to avoid false positives.
What I meant was the following situation:
Main program:
IDENTIFICATION DIVISION.
PROGRAM-ID. PP0040A.
WORKING-STORAGE SECTION.
01 FILLER PIC X(01).
88 FIRST-CONDITION VALUE "Y" FALSE "N".
01 FILLER PIC X(01).
88 SECOND-CONDITION VALUE "Y" FALSE "N".
01 LINKAGE-ITEM PIC X(01).
88 OK VALUE "Y" FALSE "N".
PROCEDURE DIVISION.
MAIN SECTION.
SET FIRST-CONDITION TO TRUE
SET SECOND-CONDITION TO TRUE
IF FIRST-CONDITION
SET OK TO TRUE
ELSE
SET OK TO FALSE
END-IF
IF OK
IF SECOND-CONDITION
CALL "PP0040B" USING LINKAGE-ITEM
END-IF
IF OK
PERFORM DO-SOMETHING
END-IF
END-IF
GOBACK
.
DO-SOMETHING SECTION.
.
Called program:
IDENTIFICATION DIVISION.
PROGRAM-ID. PP0040B.
WORKING-STORAGE SECTION.
LINKAGE SECTION.
01 LINKAGE-ITEM PIC X(01).
88 OK VALUE "Y" FALSE "N".
PROCEDURE DIVISION USING LINKAGE-ITEM.
MAIN SECTION.
SET OK TO FALSE
GOBACK
.
But if I understand your previous answer correctly, this could only lead to false negatives.
As I wrote, we don’t do cross-program analysis.
We consider that we don’t know what happens in the called program and that the items referenced in the USING clause may have been modified.
So, indeed, that could lead to false negatives, but not false positives.
