#212 Two programs with same name cause C compiler error

[Edward Hart]

For example, this

:::cobol

       IDENTIFICATION   DIVISION.
       PROGRAM-ID.      sdlsakjfkla.

       PROCEDURE DIVISION.
           CONTINUE
           .

       END PROGRAM sdlsakjfkla.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. sdlsakjfkla.

       END PROGRAM sdlsakjfkla.

causes the following error:

/tmp/cob9781_0.c:182:1: error: redefinition of ‘sdlsakjfkla’
 sdlsakjfkla ()
 ^
/tmp/cob9781_0.c:48:1: note: previous definition of ‘sdlsakjfkla’ was here
 sdlsakjfkla ()
 ^
/tmp/cob9781_0.c:188:1: error: redefinition of ‘sdlsakjfkla_’
 sdlsakjfkla_ (const int entry)
 ^
/tmp/cob9781_0.c:54:1: note: previous definition of ‘sdlsakjfkla_’ was here
 sdlsakjfkla_ (const int entry)
 ^

It would be nicer if GnuCOBOL flagged this error, rather than push the error onto the C compiler.

[Simon Sobisch]

This would mean a simple lookup of the program-ids in the first level (nested programs are likely not affected and if they are need a check in their level, not in the neighbour) and in all compiled sources (prog.cob and prog2.cob both containing program-id. prog.).

And yes: it's nice if the compiler catches this for the "simple" cases mentioned above - it won't be possible to do so in every case (program-id conflicting with a library name or an exported name of a previous compiled .o, ...).

Simon

[Edward Hart]

I've nearly finished a patch which should fix this bug and part of [bugs:#205].

However, this causes the test "Case independent [sic] PROGRAM-ID" to fail, which tests that programs in the same scope can have two names differering only in case. Is this a GnuCOBOL-only extension or do other implementations support it? This extension is very incompatible with the standard as program-names are case-insesitive and a case-sensitive, external name should be specified in the AS clause.

[Simon Sobisch]

The case issue can be true for other vendors, too, see MF's directives FOLD-CALL-NAME (change of module case for CALL) and CASE (change search of entry points). It looks like the first is for finding the module and the second for the entry point, I think GnuCOBOL uses -ffold-call for both.

If I remember this correctly ACUCOBOL first searches the module in upper-case, then lower-case, then as-is, if it is found the same is done for the entry point.

For keeping the current behaviour in GnuCOBOL please implement the check as case-dependend, change the case only if -ffold-call is active.

And you're right, this isn't according to the standards, I suggest to add a compiler configuration for this later on, the lookup check would take this into account as soon as it is in.

[Edward Hart]

Attached is the first version of the fix for this bug and [bugs:#205]. It adds checks that prevent redefinition of program and function-prototype names. Unless -ffold-call is specified, program-names are matched in a case-sensitive manner. This fix does not output pretty messages when redefinition occurs: the error message is along the lines of "unexpected User FUNCTION".

The patch is essentially complete and I only need to make the new tests more comprehensive.

[Edward Hart]

I've deleted the version of the patch attached to the above as it didn't actually fix this bug! This version does.

[Edward Hart]

Attached is the fix with completed tests.

[Simon Sobisch]

Thank you for looking at this - and thank you for providing a patch first (you manage to provide them if a discussion is helpful before and commit it directly otherwise) - I had a "quick" glance over the patch and see the following issues:

• Is the "TODO" you've added something you still want to check/do before commit or later or is it already done?
• Please try to use the special WORD tags "PROGRAM_ID", "REPO_FUNCTION" and "USER_REPO_FUNCTION" and add the necessary checks with these instead of the general tag "WORD". This keeps the structure and helpful error messages.
  In the case of "PROGRAM_ID" it could work to only set yyval depending on cb_fold_call in scanner.l and do the additional check in parser only if it isn't a literal.
• typo seen in: "Redifinition"

Additional issue: I think the externalized name given by AS should always be case-sensitive, no matter how -ffold-call is set. Do you agree? (I know it wasn't before, but I've recognized the full encoding the first time). The Standard says: "that AS phrase is a name that is externalized to the operating environment. The implementor defines the formation and mapping rules of these names." (therefore the current implementation doesn't seem wrong) but also adds the note "The AS phrase provides a way to specify names that are either case-sensitive or not valid COBOL words. Such names may be required by other programming languages or system components."

[Edward Hart]

Is the "TODO" you've added something you still want to check/do before commit or later or is it already done?

It's something I wanted to do before committing. I've now done them.

Please try to use the special WORD tags "PROGRAM_ID", "REPO_FUNCTION" and "USER_REPO_FUNCTION" and add the necessary checks with these instead of the general tag "WORD". This keeps the structure and helpful error messages.
In the case of "PROGRAM_ID" it could work to only set yyval depending on cb_fold_call in scanner.l and do the additional check in parser only if it isn't a literal.

Done.

typo seen in: "Redifinition"

Nice one; done.

I think the externalized name given by AS should always be case-sensitive, no matter how -ffold-call is set. Do you agree?

Yes, that's correct. I believe I've fixed any code that acts otherwise in this version (except a bit to do with functions, which I'll fix in a subsequent commit for [bugs:#217]).

[Simon Sobisch]

Nearly ready to commit, the only change is one for the translators: please change _("END %s '%s' is different to PROGRAM-ID '%s'") to be called twice, changing the first %s to the actual type (otherwise translators won't know what this is, I've done things like that before, too but was teached by the translation project that it's better to have two msgids instead). I still like the change to setup/clean_up_program.

Big Thanks.

[Edward Hart]

Committed in [r823].