Actually obey `-fdefault-colseq`

[nberth]

… which currently seems ignored for alphanumeric comparisons others than in SORT.

[codecov-commenter]

Codecov Report

Merging #101 (db0cc1b) into gcos4gnucobol-3.x (8caf9b2) will increase coverage by 0.01%. The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@                  Coverage Diff                  @@
##           gcos4gnucobol-3.x     #101      +/-   ##
=====================================================
+ Coverage              65.21%   65.22%   +0.01%     
=====================================================
  Files                     31       31              
  Lines                  58313    58313              
  Branches               15352    15352              
=====================================================
+ Hits                   38026    38033       +7     
+ Misses                 14362    14352      -10     
- Partials                5925     5928       +3     

see 2 files with indirect coverage changes

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[nberth]

@GitMensch Here's a bit of context on this.

While investigating a weirdly functioning SEARCH ALL, I actually observed that the resulting search algorithm did not operate according to any user-given collating sequences if (and only if) that sequence was specified using -fdefault-colseq. Other means of specifying the collating sequence (e.g, via the ENVIRONMENT DIVISION) seemed to make the search work properly. Turns out that issue was worse than I expected, and impacted "regular" comparisons between fields.

Investigating further, it seems constant-folding does not operate according to the proper collating sequence. And it may also be the case that fast-comparisons (-ffast-compare) are also impacted.

A seemingly "easy" way to mitigate the last points would be to check on the status of (current_)prog->collating_sequence when performing constant folding and/or optimizing comparisons.

[GitMensch]

Ideally both points would do the check via libcob functions and passing the collation.

[nberth]

Ideally both points would do the check via libcob functions and passing the collation.

Yes that would be ideal indeed. However, I don't think I'll have the time to implement that new approach right now (but I'd happily give it a try). May I suggest pushing the current PR upstream first, as this is primarily a bugfix?

(In the meantime, I've also added a test for SEARCH ALL.)