Allow paragraph names to redefine field and section names #31

ddeclerck · 2022-03-28T13:50:40Z

This allows a paragraph to have the same name as a previous field or section.

It is not clear whether this is actually allowed or not by the standard or the GCOS dialect, however our customer does have Cobol programs where some paragraphs have the same name as fields or sections. Further discussion is probably required.

Below are the relevant excerpt from the standards for reference.

Both the COBOL 85 standard and GCOS say :

Within a given source program, but excluding any contained program, the user-defined words are grouped into the following disjoint sets:
{ ..., data-names, ..., paragraph-names, ..., section-names, ... }
All user-defined words, except segment-numbers and level-numbers, can belong to one and only one of these disjoint sets. Further, all user-defined words within a given disjoint set must be unique, except as specified in the rules for uniqueness of reference.

(nb: these rules say nothing about paragraphs)

The 2014 standard is a bit different :

Within a source element, a given user-defined word may be used as only one type of user-defined word with the
following exceptions:

a compilation-variable-name may be the same as any other type of user-defined word

a level-number may be the same as a paragraph-name or a section-name

the same name may be used as any of the following types of user-defined words:

constant-name

data-name

property-name

record-key-name

record-name

The wording in item 3 is rather ambiguous...

GitMensch · 2022-03-28T14:20:26Z

It seems this is https://sourceforge.net/p/gnucobol/feature-requests/260 - in this case please check the discussion there and let us discuss the issue itself there (patches and changes here are still ok).

nberth · 2022-05-20T13:35:20Z

(Marked as WIP as awaiting a rebase w.r.t gcos4gnucobol-3.x)

GitMensch · 2022-05-25T17:33:19Z

You've likely done that - but the actual syntax test is missing; it should cover:

data name and paragraph name identical
data name and section name identical

is there more? I think this can go "upstream" very soon, I guess you want to commit a GCOS base commit with NEWS entry and -std (so conf and words) first.

GitMensch · 2022-05-25T17:42:28Z

The test from the FR may be used - word.cob

       identification division.
       program-id. word.
       data division.
       working-storage section.
      *-----------------------------------------------------------------
       77 word  pic 9.
       77 word2 pic x.
      *-----------------------------------------------------------------
       PROCEDURE DIVISION.
       main section.
      *
           move 0 to word
           perform word
      *
           exit program returning word.
      *-----------------------------------------------------------------
       entry "word2".
       word section.
      *
           add 1 to word
           if word = 2 goto word2.
           add 1 to word.
      *
       word2.
      *
           continue.
      *-----------------------------------------------------------------

GitMensch

Some minor adjustments needed, but nearly finished - the SF feature-request is now assigned to you, too :-)

config/acu-strict.conf

config/bs2000-strict.conf

config/default.conf

config/ibm-strict.conf

config/mvs-strict.conf

config/mf-strict.conf

config/realia-strict.conf

config/rm-strict.conf

cobc/config.def

GitMensch

in general this could be either committed before or after the GCOS "base commit"

GitMensch · 2022-05-30T18:58:28Z

cobc/error.c

+	default:
+		return 0;
+	}
+#ifndef _MSC_VER


This should not be necessary because of the default above returns like all other paths. But if I remember correctly the "multiple case, then default" will raise a warning with different compilers, maybe drop that #ifndef and the case statements before the default?
Note: I'm always open to learn something new, maybe I've missed something?

It's just an occurrence of careless copy-paste (I made this function by copying cb_verify_x). Indeed the #ifndef should not be necessary.
I'm not aware of compilers specifically warning for falling through "into" the default case, though some compilers do have warnings (usually disabled) for fall-through in general.
Anyways, I'll just remove the default case and let the function return 0.

GitMensch · 2022-05-30T19:11:15Z

cobc/typeck.c

@@ -1938,8 +1938,15 @@ cb_build_section_name (cb_tree name, const int sect_or_para)
 		if (!CB_LABEL_P (x) || sect_or_para == 0 ||
 		    (sect_or_para && CB_LABEL_P (x) &&
 		    CB_LABEL (x)->flag_section)) {
-			redefinition_error (name);
-			return cb_error_node;
+			if (cb_is_supported(cb_non_unique_procedure_names) &&


Shouldn't this be something like:

if ((CB_FIELD_P (x) || (CB_LABEL_P (x) && CB_LABEL (x)->flag_section))) { cb_verify (cb_non_unique_procedure_names, _("non-unique procedure-name")); } else { redefinition_error (name); return cb_error_node; }

I considered that first, but that would generate a different error message when a field or section name redefinition is forbidden by the non-unique-procedure-name option being set to error or unconformable (I wanted the error message to remain the same, regardless of the reason why the redefinition is forbidden).

GitMensch · 2022-05-30T19:14:31Z

tests/testsuite.src/syn_definition.at

+[prog.cob: in section 'L':
+prog.cob:6: warning: non-unique section or paragraph name used
+])
+AT_CHECK([$COMPILE_ONLY -fnon-unique-procedure-names=error prog.cob], [1], [],
 [prog.cob: in section 'L':
 prog.cob:6: error: redefinition of 'L'
 prog.cob:5: note: 'L' previously defined here


the FIXME below can be removed

Is everything of https://github.com/OCamlPro/gnucobol/pull/31#issuecomment-1137626598 already covered? If not then please add it as new testcase compiling once without std (expected warning with zero status) and with -std-cobol2002 (expecting error -> status 1)

I've added the new test; for now it does not pass and reports an ambiguity. We are currently checking whether this one should indeed pass on GCOS.

On that note, the FR links to a former implementation are all broken. Is there another place where that previous attempt can be investigated?

Ah, yes these are the old artifact links, just replace "open-cobol" in the URL with "gnucobol" to fix those manually.

Ah yes indeed; somehow I had forgotten that was a former name for gnucobol.

Anyways, as far as our tests go, GCOS appears to subject uses of identical names for sections/paragraphs and data to syntactic scoping rules (as mentioned by David in the FR). This is the behavior of the current implementation.
For this reason we should expect the test cases imported from the FR to fail.

If there's a section and a paragraph defined and you have PERFORM same-name in GCOS that is auto-scoped?
So if you do it from main section it will call the section with that name, but if you call it from other-section that has the same-name paragraph defined it uses that?
I'm a bit skeptic.

If there's a section and a paragraph defined and you have PERFORM same-name in GCOS that is auto-scoped?
So if you do it from main section it will call the section with that name, but if you call it from other-section that has the same-name paragraph defined it uses that?
I'm a bit skeptic.

The part "what does GCOS do if there is both a section and a paragraph name with the same word" is the most important one not answered (or - totally possible: answered but I've overlooked that).

Would it be useful to go with a lesser version first that matches the old FR? This would be procedure-shares-data-name or similar.

tests/testsuite.src/syn_definition.at

GitMensch · 2022-10-04T18:54:01Z

Would it be useful to go with a lesser version first that matches the old FR? This would be procedure-shares-data-name or similar [hopefully with a better name, because once found we should not change it in any 3.x].

friendly ping

nberth · 2022-10-05T12:04:48Z

friendly ping

Our migration project does not appear to require this anymore. As this may still be quite useful for other cases, I'll try to see if I can do something quick after a rebase/merge on gcos4gnucobol-3.x in the coming days; if not I'm afraid this will need to wait as I do not have much time to allocate on that in the short term.

GitMensch · 2023-06-19T18:50:19Z

friendly ping to recheck if this can be rebased and possibly "slimmed down" a bit for now

Would it be useful to go with a lesser version first that matches the old FR? This would be procedure-shares-data-name or similar [hopefully with a better name, because once found we should not change it in any 3.x].

... actually it would then likely be more reasonable to start in a new (recent) branch and "only" add the "slimmed down" code there, handling the rebase here after we merged that new "slim" version

ddeclerck force-pushed the relax_paragraph_section_name_uniqueness branch 3 times, most recently from 8846569 to b9125e9 Compare March 29, 2022 12:23

nberth changed the title ~~Allow paragraph names to redefine field and section names~~ [WIP] Allow paragraph names to redefine field and section names May 20, 2022

GitMensch requested changes May 25, 2022

View reviewed changes

ddeclerck force-pushed the relax_paragraph_section_name_uniqueness branch from b9125e9 to 1d1b32f Compare May 30, 2022 08:28

ddeclerck changed the base branch from old-gcos4gnucobol-3.x to gnucobol-3.x May 30, 2022 08:29

ddeclerck changed the base branch from gnucobol-3.x to gcos4gnucobol-3.x May 30, 2022 08:30

ddeclerck force-pushed the relax_paragraph_section_name_uniqueness branch 2 times, most recently from 8677b94 to ceaa925 Compare May 30, 2022 15:01

GitMensch requested changes May 30, 2022

View reviewed changes

nberth force-pushed the relax_paragraph_section_name_uniqueness branch 2 times, most recently from b7e3028 to d9b858f Compare June 22, 2022 07:54

Allow paragraph names to redefine field and section names

5a44c20

nberth force-pushed the relax_paragraph_section_name_uniqueness branch from d9b858f to 5a44c20 Compare June 22, 2022 08:50

nberth marked this pull request as draft July 8, 2022 09:04

nberth changed the title ~~[WIP] Allow paragraph names to redefine field and section names~~ Allow paragraph names to redefine field and section names Jul 8, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow paragraph names to redefine field and section names #31

Allow paragraph names to redefine field and section names #31

ddeclerck commented Mar 28, 2022 •

edited

Loading

GitMensch commented Mar 28, 2022

nberth commented May 20, 2022

GitMensch commented May 25, 2022

GitMensch commented May 25, 2022 •

edited

Loading

GitMensch left a comment

GitMensch left a comment

GitMensch May 30, 2022

ddeclerck May 31, 2022

GitMensch May 30, 2022

ddeclerck May 31, 2022

GitMensch May 30, 2022

GitMensch May 30, 2022

nberth Jun 21, 2022

GitMensch Jun 21, 2022

nberth Jun 22, 2022

GitMensch Jun 25, 2022

GitMensch Sep 7, 2022

GitMensch commented Oct 4, 2022 •

edited

Loading

nberth commented Oct 5, 2022

GitMensch commented Jun 19, 2023

Allow paragraph names to redefine field and section names #31

Are you sure you want to change the base?

Allow paragraph names to redefine field and section names #31

Conversation

ddeclerck commented Mar 28, 2022 • edited Loading

GitMensch commented Mar 28, 2022

nberth commented May 20, 2022

GitMensch commented May 25, 2022

GitMensch commented May 25, 2022 • edited Loading

GitMensch left a comment

Choose a reason for hiding this comment

GitMensch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GitMensch commented Oct 4, 2022 • edited Loading

nberth commented Oct 5, 2022

GitMensch commented Jun 19, 2023

ddeclerck commented Mar 28, 2022 •

edited

Loading

GitMensch commented May 25, 2022 •

edited

Loading

GitMensch commented Oct 4, 2022 •

edited

Loading