#205 upper / lower case not consistent

[wim niemans]

A function wit id cgivalue having a linkage section defining a data name cgiValue.
Note the uppercase V. The function compiles fine.
However, adding some references in the PROCEDURE DIVISION to the dataname cgiValue:

• The compiler recognizes in the PROCEDURE DIVISION the data name cgiValue being a udf.
• Compiler error syntax error, unexpected User FUNCTION in cases.

• Compiler fauilure unsigned char[4] not assignable in cases, when cgiValue is defined as binary-long.

• Changing all the naming into CGIVALUE compiles fine, though a compiler error would be expected.

• Referencing the dataname CGIVALUE gives the same results.

I can't find constraints on datanames in the GC2.0 Cobol Reference manual.

[Edward Hart]

Example code:

:::cobol
       IDENTIFICATION DIVISION.
       FUNCTION-ID. cgivalue.

       DATA DIVISION.
       LOCAL-STORAGE SECTION.

       LINKAGE SECTION.
       01  x PIC 99999.
       01  cgiValue PIC 99999.

       PROCEDURE DIVISION USING x RETURNING cgiValue.
           IF x = 0 THEN
               MOVE FUNCTION cgiValue TO x
           END-if.
           MOVE 1 TO X
           .
       END FUNCTION cgivalue.

The root bugs:

• the cgiValue variable is not rejected for having the same name as the function
• cannot recurse inside the function

• Compiler fauilure unsigned char[4] not assignable in cases, when cgiValue is defined as binary-long.
• Changing all the naming into CGIVALUE compiles fine, though a compiler error would be expected.

I've been unable to reproduce these. Could you post some code which demonstrates these bugs?

[wim niemans]

The example shown by Edward does not compile. There is the error on line 13

 FUNCTION 'cgiValue' unknown

which seems to be a correct diagnose. Than changing line 13

              MOVE FUNCTION cgiValue TO x

into

              MOVE 15 to cgiValue

gives the error on line 13

syntax error, unexpected User FUNCTION 

The other cases are more complicated. I'll see to show a good example.

[wim niemans]

Than, by accident, found out that these statements enjoy different compiler behaviour:

MOVE FUNCTION cgiValue TO x
MOVE FUNCTION cgivalue TO x
MOVE FUNCTION cgivalue(x) TO x

all errors with FUNCTION cgiValue' unknown. Note the lowercase v in the statement and the upercase V in the error.

MOVE cgiValue(x) TO x
MOVE cgiValue TO x
MOVE cgivalue(x) TO x
MOVE cgivalue TO x

all compile fine. Note the uppercase V.

[wim niemans]

It took a while to recall the construct I've stumbled upon. On second thought it probably doesn't have a link to upper/lower cases, but it showed in the process to find out what was happening. The problem was that the call "cgiGetValue" using cgiName returning cgiValue persistently errors with syntax error, unexpected User FUNCTION, expecting Identifier on cgiValue, and I tried something different, see below.
The error received brought me to decide it was the upper/lower case of cgiValue causing the troubles.

identification division.
function-id.    cgivalue.
 *>author. wim niemans, rotterdam
environment division.
data division.
working-storage section.
01  newValue       usage binary-long.
linkage section.
01  cgiName  any length pic x.
01  cgiValue       usage binary-long.
01  indexValue     usage binary-char.
procedure division using cgiName, indexValue returning newValue.
0000-main-frame.
*> do something:
    display "received " cgiName.
    call "cgiGetValue" using cgiName returning newValue.
    display "than " cgiValue.
009-einde.
    exit function.
end function cgivalue.

which shows the error, without a line reference:

warning: unknown remark option '-R/opt/local/lib' [-Wunknown-warning-option]
/var/folders/kc/cpx3q67j2y3g1c72jy6txkxm0000gn/T//cob5350_0.c:117:7: error: array type 'unsigned char [4]' is not assignable
  b_6 = cob_malloc (4U);
  ~~~ ^
1 warning and 1 error generated.

Having the PROCEDURE DIVISION returning cgiValue (instead of newValue), compiles fine, though.
Finally, I am on iMac OS/X, got gnuCobol 2.0 from macports.org and I am using openCobolIDE.

[wim niemans]

Than. the next oddity. Function is cgivalue returning myCgiValue.

Changed the datanames from cgiValue into myCgiValue, but forgot one statement:

The statement display cgiValue. compiles fine, but the exec delivers a SEGV.

[Edward Hart]

This bugs appears fixed as of [r827]. Function-names now generate an implicit REPOSITORY entry, which prevents users from using the same name for data items.

The errors regarding CALL are caused by program-names being matched in a case-sensitive way by default. More standard behaviour can be enabled by using -ffold-call.