New module `cobc/cconv` for EBCDIC & ASCII conversion tables

[codecov-commenter]

Codecov Report

Merging #63 (d3c76ad) into gcos4gnucobol-3.x (8705127) will increase coverage by 0.06%. The diff coverage is 75.53%.

@@                  Coverage Diff                  @@
##           gcos4gnucobol-3.x      #63      +/-   ##
=====================================================
+ Coverage              64.65%   64.72%   +0.06%     
=====================================================
  Files                     32       33       +1     
  Lines                  54866    54792      -74     
  Branches               14262    14281      +19     
=====================================================
- Hits                   35474    35463      -11     
+ Misses                 13760    13693      -67     
- Partials                5632     5636       +4     

Impacted Files	Coverage Δ
cobc/codegen.c	73.68% <69.73%> (+0.50%)	:arrow_up:
cobc/cconv.c	100.00% <100.00%> (ø)
cobc/cobc.c	70.42% <100.00%> (+0.03%)	:arrow_up:
cobc/flag.def	100.00% <100.00%> (ø)
cobc/help.c	100.00% <100.00%> (ø)
libcob/strings.c	68.92% <0.00%> (+0.21%)	:arrow_up:

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

[nberth]

Will you tackle -febcdic-table

Yes I'll try do do this quick.

[nberth]

@GitMensch I can anticipate dealing with cases where COB_EBCDIC_MACHINE holds being a bit of a challenge. Unless we clearly specify what this actually means in terms of the native encoding… (also I don't think I/we have any simple way to test that).

[GitMensch]

I can anticipate dealing with cases where COB_EBCDIC_MACHINE holds being a bit of a challenge. Unless we clearly specify what this actually means in terms of the native encoding… (also I don't think I/we have any simple way to test that).

As noted before that only means that the space is not hex 20 which means "any EBCDIC". I actually expect to find some issues via testcase when running 3.2-rc1 on those machines which I will then fix with either rc2 or 3.2 final. As long as you don't see that something must be completely broken there - feel free to check that in.

[nberth]

now upstream

[GitMensch]

Just a note: when checking for copyrights of that module I've found the place where the "alternative" came from: that's https://sourceforge.net/p/gnucobol/history/2539 with some explanation and then https://sourceforge.net/p/gnucobol/history/2540#diff-4 (but sadly neither the VCS log comment nor the Changelog explain much here on that).

[GitMensch]

The inclusion of stdio in cobc.h broke VS builds, see https://ci.appveyor.com/project/GitMensch/gnucobol-3-x-vs/builds/44939738 (it may be a good idea to include those in the local CI action ;-)

For now I've reverted this part of the change, which solved that https://ci.appveyor.com/project/GitMensch/gnucobol-3-x-vs/builds/44939945 - we'll have a look at it when inspecting cobc for more separation of modules.

[GitMensch]

Just a note: shortly after this was implemented the question came up "what about other EBCDIC encodings" - and the idea to handle the option to -febcdic-table - if it doesn't match to one of the default names (or if it includes a period) as a file name; checking if it exists in COB_CONFIG_DIR and if it does if the file contains exactly 512 bytes - when yes set the cb_ebcdic_table to a new entry GC_EBCDIC_USER and store its content as two static variables in ccovnc - to return those for conversions.

I wanted to at least drop that idea here.