Add optional index check in 3.x#191
Add optional index check in 3.x#191ddeclerck wants to merge 5 commits intoOCamlPro:gcos4gnucobol-3.xfrom
Conversation
| continue; | ||
| } | ||
| } | ||
| if (cb_subscript_check != CB_SUB_CHECK_MAX |
There was a problem hiding this comment.
That's where I'm wondering if the added lines above interact badly with this.
There was a problem hiding this comment.
No need to wonder (my guess is this breaks cb_subscript_check: max) - but a reason to add this into the "enable / disable subscript check with ODO" test (run_subscripts.at) tests, which should get a prog2.cob in any case that uses an index in any case (which should behave identical for the current tests but likely break with the new option [which only makes sense in the prog2.cob test as it only applies to indexes).
... while you at this: please replace the leading tabs in that test's prog.cob.
There was a problem hiding this comment.
Actually this was removed from trunk in the subsequent commit (4954).
GitMensch
left a comment
There was a problem hiding this comment.
This is a new cobc option and should have an entry in the NEWS.
Your guess about the broken combination is likely correct and you'd need to adjust the new code to also include the new dialect option added in the meantime - but the (currently missing) extended test case will show if this is the case.
Note: please reword the help in flag.def, maybe something like "for index-names, don't apply EC-BOUND-SUBSCRIPT on subscript use per ISO rules but but on adjusting the index-name via SET or PERFORM statements, to reduce the amount of checks done".
I also wonder if we should place "index" into that option somewhere...
Please include into cobc/Changelog both Ron's original entry (with a remark "merged on YYYY-MM-DD as new option) and your on-top changes (the option and possibly inclusion into the dialect code) with that date.
| continue; | ||
| } | ||
| } | ||
| if (cb_subscript_check != CB_SUB_CHECK_MAX |
There was a problem hiding this comment.
No need to wonder (my guess is this breaks cb_subscript_check: max) - but a reason to add this into the "enable / disable subscript check with ODO" test (run_subscripts.at) tests, which should get a prog2.cob in any case that uses an index in any case (which should behave identical for the current tests but likely break with the new option [which only makes sense in the prog2.cob test as it only applies to indexes).
... while you at this: please replace the leading tabs in that test's prog.cob.
|
Actually I'm not very confident I could do that quickly enough. I'd rather delegate this so I could focus on the GC3/GC4 merge - the clock's ticking and the days allocated to this task are almost depleted. |
|
I was surprised you took on that backport. The issue that I've now realized is - if you want to merge the dialect option from GC3 to GC4 then this has to be done in any case :-/ |
True indeed ; that dialect option is commit 5087 (so this will be a problem in ~50 commits). Though I'm just realizing now that feature was implemented by Nicolas ; I'm gonna ask him for help. |
02e51ce to
e27d944
Compare
|
MSVC CI should be fixed with updating from upstream (I've worked on that before my vacation). Apart from that: What is the state of this PR? |
I'd stay "stale" - waiting for someone else to take over. |
e27d944 to
20a071f
Compare
20a071f to
e7c9540
Compare
GitMensch
left a comment
There was a problem hiding this comment.
... oops, forget to send "submit"... so here is my (6 weeks old?) review, requesting changes.
| PROCEDURE DIVISION. | ||
| MOVE 5 TO MAXIDX | ||
| SET NIDX TO IB1. | ||
| DISPLAY "Initial value: " NIDX. |
There was a problem hiding this comment.
this is unrelated - if we haven't tested that yet, then it should be a separate test (run once with std=default and -std=ibm and once with std=mf (output only "bigger than max" as the value will be different with 32/64 bit there)
f44e6a6 to
82b76e4
Compare
GitMensch
left a comment
There was a problem hiding this comment.
First: Sorry that the review took so long. I did not submit it before; but that second view now actually brought some more "content" in, so that's possibly not bad.
The non-standard check as possible performance boost while keeping checks enabled are not an actual part of this PR (so far).
Depending on how you want to go on, we could reduce this PR to syntax improvement (parser) and the additional useful warning - and drop the change top flag.def.
Then maybe create a follow-up PR which has the additional move to the non-standard RANGE check (or postpone this for later).
... or: work on this to get this "all in"; but that will definitely be more work for nowö.
| " * turned on by --debug/-g")) | ||
|
|
||
| CB_FLAG (cb_flag_check_subscript_set, 1, "opt-check-subscript-set", | ||
| _(" -fopt-check-subscript-set check subscript in PERFORM/SET")) |
There was a problem hiding this comment.
The current implementation has only the check for SET, not for PERFORM - has it?
There was a problem hiding this comment.
The change in codegen.c impacts PERFORM UNTIL; I assume that's why PERFORM is mentioned here. however, that specific part in code-generation might be about internal SETs induced by PERFORM statements. If so, then indeed there's not real point in mentioning PERFORM here.
cobc/typeck.c
Outdated
| if (emit_exception) { | ||
| cb_emit (CB_BUILD_FUNCALL_1 ("cob_set_exception", | ||
| cb_int (COB_EC_RANGE_INDEX))); | ||
| } |
There was a problem hiding this comment.
the code around this is definitely useful; the fixed non-standard EC-RANGE exception in the compiled code is only useful when we do the same for common SET (run-time values) and skip the subscript exception runtime check for use of indexes later
There was a problem hiding this comment.
I'm not sure I fully understand this comment… not to mention what change would be needed in the code ;-)
(Apologies for the request for clarification: I'm just discovering this PR).
|
Just stumbled over this, maybe the parser change already handles the issues mentioned in https://sourceforge.net/p/gnucobol/bugs/228/ (or can be extended to that)? |
No it does not. Is it only about raising an error/warning in this case (maybe with/without a dialect option)? |
This PR attemps to backport SVN commit 4953 4954 & 5358 to 3.x.