#217 AS clause used for function name

[Edward Hart]

GnuCOBOL treats the literal defined in the AS clause of the FUNCTION-ID clause as that element's name. However, the AS clause specifies the name externalised to the operating environment, not to the rest of the COBOL program.

For instance, the following is valid:

:::cobol
       IDENTIFICATION DIVISION.
       FUNCTION-ID. foo.
       *> ...
       END FUNCTION foo.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. testing.

       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       REPOSITORY.
           *> Identify function by alias
           FUNCTION whatever AS "foo"
           .
       PROCEDURE DIVISION.
           DISPLAY FUNCTION whatever()
           .
       END PROGRAM testing.

as is

:::cobol
       IDENTIFICATION DIVISION.
       PROGRAM-ID. testing.

       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       REPOSITORY.
           *> Identify function by definition name
           FUNCTION foo
           .
       PROCEDURE DIVISION.
           DISPLAY FUNCTION foo()
           .
       END PROGRAM testing.

GnuCOBOL rejects both, complaining that it cannot identify the function "whatever" and the function "foo", respectively.

(There is a related bug regarding programs (although it might be a feature). A program with AS "foo" can be successfully called with CALL "foo". However, the CALL literal should refer to the COBOL program-name, not the externalised name, so this shouldn't work. I suspect this is a necessary consequence of letting users CALL C functions.)

[Simon Sobisch]

As you have set yourself as owner I've assigned [bugs:#124] to you, too.

Concerning the programs: both should be usable in GnuCOBOL (COBOL and externalized name), and yes: only because of the externalization via C.

[Edward Hart]

Fixed in [r825]. Note that the AS clause in the REPOSITORY actually identifies the function-name, not the external name, as I thought earlier.

[Simon Sobisch]

These are really nice changes!
Please add a test entry (the added ones were nice, too) for the recursive call of functions.

BTW: It's wonderful to see you making progress that fast!

[Edward Hart]

I was going to, but recursion doesn't work. I'm going to add a bug now.

[Edward Hart]

Actually, I was right before: the AS clause does give the external name. The syntax rules of the REPOSITORY state that the literal AS gives the "name" of the function/program/etc. which I took to be the internal, function/program/etc.-name. Only later does the standard clarify that the literal identifies the external name.

Looking at it now, I'm still confused as to what the REPOSITORY phrases are identifying. I might complain to the standards committee.

I'll post the correct implementation as part of the fix to [bugs:#124].

[Simon Sobisch]

You've added a new warning in [r825] which is fine in general. Please add a new warning option for this as this possibly effects a lot of programs and currently cannot be disabled (I'm fine with including it in -Wall).
And please explain the "real" fix to Mario Matos at [36b4854f].

Thank you.

BTW: All warnings for missing prototypes have the same line number (I guess it is the last one), it could be better to not display the line number in this case, isn't it?

[Edward Hart]

Everything should now be fixed in [r829].

[Simon Sobisch]

Thank you, this likely helps Mario. Can you please fix run_functions.at and syn_functions.at to not show these warnings despite of the test cases which should actually result in these?

[Edward Hart]

Sure: done in [r830]. I also added an entry for -Wno-<warning name> to the --help output.

[Simon Sobisch]

This is cheating ;-)

Please don't suppress the warnings but fix them in the code - helps as a minimal documentation how to do it, too.

[Edward Hart]

Done (finally) in [r841].