Menu ▾ ▴

#347 add more options to do truncation on different USAGEs of numeric fields

GC 3.0
accepted
Ron Norman
truncation (1) binary (1)
1 - highest
2018-12-16
2018-11-20
Simon Sobisch
No

Orignally this was a "bug report" with the following content:

The attached test program shows that 9.85 from a 9v99 to a v99 field is only 0.85 if the fields are USAGE DISPLAY.
It works correctly with GnuCOBOL 1.1 but doesn't work with any 2. x+ version (including rw-branch).

I'm really shocked that this did not came up before! It would be good to check the truncation with any combination of USAGE...

But this should be considered a "different behaviour" instead (for details see post from 2018-12-16).
This issue is now used to track feature-request to allow truncation options according to mulitple compilers (including GnuCOBOL 1.1).

In general: IBM as well as Micro Focus and OpenCOBOL/GnuCOBOL 2.x+ all do NO data truncation to the PIC clause for COMP-5.
All these do truncate fields defined with USAGE BINARY/COMP-4, but only depending on a specified option/flag.
OpenCOBOL/GnuCOBOL 1.1 (and earlier, which is actually what many people that start to move
to GnuCOBOL 2.2+ currently use) do truncate COMP-5 and BINARY without any option (default).

What I suggest is:

  1. Add an enum compiler configuration option to define how truncation is done (we currently have a yes/no option). I vote for the name "truncation" (will work without any conflict as neither -fno-trunc nor -ftrunc were accepted until now).

The most reasonable configuration set is the one that the most recent ACUCOBOL version provides (likely the most recent MicroFocus has the same option set with different option names/values) [instead of the ACU switches I've used possible enum values, please check if they are reasonable/correct]

Option Behavior
ansi Full ANSI COBOL rules are in place. Each numeric data item stores values up to its PICTURE in size. A small number of USAGE types provide exceptions (such as COMP-X). These are documented under the USAGE phrase. Values larger than allowed by the PICTURE are truncated using the standard size rules when the data item is the target of a MOVE statement. The results of an arithmetic overflow (without the SIZE phrase) are undefined.
ibm Similar to the default, but COMP-5 is added to the list of data types that ignore their PICTURE when determining the largest value they can hold. However, COMP-5 items do use their PICTURE when moving a value to a nonnumeric data item.
binary All binary data types ignore their PICTURE when determining the largest value they can hold. However, the PICTURE is used when moving data from a binary number to a nonnumeric data item.
binary-packed All binary and packed-decimal data types ignore their PICTURE when determining the largest value they can hold. The PICTURE is not used when moving to a nonnumeric destination (the largest possible value determines the number of digits moved instead).

-fnotrunc should set whatever of these values was used before in 2.2+; possibly we need another "compat-notrunc" enum value...

  1. the compiler configurations are set to a matching value, if in doubt use "standard # not verified yet".

  2. We have test cases that verify each of the four options (with any binary/packed and DISPLAY USAGE, checking truncation for both the integer and decimal part [should be identical, but testing is better...]).

1 Attachments
bintrunc.cob

Discussion

  • Ron Norman

    Ron Norman - 2018-11-20

    Using Micro Focus the results are:

    target .85 wrong
    display: 85
    binary : 217

    --
    Cheers
    Ron Norman

     

    Last edit: Simon Sobisch 2018-11-20

  • Simon Sobisch

    Simon Sobisch - 2018-11-20

    ... yay, GnuCOBOL 2+ shows exactly the same result as MicroFocus, so we need to at least have an option to keep the >=2 behaviour. Providing an option to get the <2.0 behaviour seems to be good, too...

    @Ron: Does this depend on compiler flags and/or std settings with MF?
    @Edward/Brian: What does the standard say about binary truncation of decimal places?

     

  • Ron Norman

    Ron Norman - 2018-11-21

    The test program is using COMP-5 and if changed to COMP-4 then numeric truncation does happen and the results match Micro Focus.
    Should there be a GnuCOBOL compile option to handle numeric truncation for native machine binary fields such as COMP-5, SIGNED/UNSIGNED SHORT/INT/LONG or COMP-X?
    Only do truncation of there was an actual PIC 9(x) coded for the 'machine binary' data field.

     

  • Simon Sobisch

    Simon Sobisch - 2018-12-16

    Ron made related changes in [r2785] and [r2786], they're just merged to trunk with [r2800].

    In general this should be not considered as a bug but as a difference with the result that GnuCOBOL 2+ is more compatible to a MicroFocus. To retain old behaviour when migrating from OpenCOBOL/GnuCOBOL 1.1 we'd need a new option which is a FR...

     

  • Simon Sobisch

    Simon Sobisch - 2018-12-16

    Ticket moved from /p/open-cobol/bugs/558/

     

  • Simon Sobisch

    Simon Sobisch - 2018-12-16
    • summary: truncation does not work on binary numeric fields --> add more options to do truncation on different USAGEs of numeric fields
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,4 +1,35 @@
-The attached test program shows that 9.85 from a 9v99 to a v99 field is only 0.85 if the fields are `USAGE DISPLAY`. 
-It works correctly with GnuCOBOL 1.1 but doesn't work with any 2. x+ version (including rw-branch).
+Orignally this was a "bug report" with the following content:

-I'm really shocked that this did not came up before! It would be good to check the truncation with any combination of `USAGE`...
+> The attached test program shows that 9.85 from a 9v99 to a v99 field is only 0.85 if the fields are `USAGE DISPLAY`. 
+> It works correctly with GnuCOBOL 1.1 but doesn't work with any 2. x+ version (including rw-branch).
+>
+> I'm really shocked that this did not came up before! It would be good to check the truncation with any combination of `USAGE`...
+
+But this should be considered a "different behaviour" instead (for details see post from 2018-12-16).
+This issue is now used to track feature-request to allow truncation options according to mulitple compilers (including GnuCOBOL 1.1).
+
+In general: IBM as well as Micro Focus and OpenCOBOL/GnuCOBOL 2.x+ all do NO data truncation to the `PIC` clause for `COMP-5`.
+All these *do* truncate fields defined with `USAGE BINARY`/`COMP-4`, but only depending on a specified option/flag.
+OpenCOBOL/GnuCOBOL 1.1 (and earlier, which is actually what many people that start to move
+to GnuCOBOL 2.2+ *currently* use) do truncate `COMP-5` and `BINARY` without any option (default).
+
+What I suggest is:
+
+1. Add an **enum* compiler configuration*** option to define how truncation is done (we currently have a yes/no option). I vote for the name "truncation" (will work without any conflict as neither `-fno-trunc` nor `-ftrunc` were accepted until now).
+
+The most reasonable configuration set is the one that the most recent [ACUCOBOL version provides][1] (likely the most recent MicroFocus has the same option set with different option names/values) [instead of the ACU switches I've used possible enum values, please check if they are reasonable/correct]
+
+[1]:https://www.microfocus.com/documentation/extend-acucobol/1020/extend-Interoperability-Suite/BKUSUSCOMPUS2.2.10.1.html
+
+Option |  Behavior
+--------- | -----------
+ansi | Full ANSI COBOL rules are in place. Each numeric data item stores values up to its PICTURE in size. A small number of USAGE types provide exceptions (such as COMP-X). These are documented under the USAGE phrase. Values larger than allowed by the PICTURE are truncated using the standard size rules when the data item is the target of a MOVE statement. The results of an arithmetic overflow (without the SIZE phrase) are undefined.
+ibm         |  Similar to the default, but COMP-5 is added to the list of data types that ignore their PICTURE when determining the largest value they can hold. However, COMP-5 items do use their PICTURE when moving a value to a nonnumeric data item.
+binary     |   All binary data types ignore their PICTURE when determining the largest value they can hold. However, the PICTURE is used when moving data from a binary number to a nonnumeric data item.
+binary-packed | All binary and packed-decimal data types ignore their PICTURE when determining the largest value they can hold. The PICTURE is not used when moving to a nonnumeric destination (the largest possible value determines the number of digits moved instead).
+
+`-fnotrunc`  should set whatever of these values was used before in 2.2+; *possibly* we need another "compat-notrunc" enum value...
+
+2. the compiler configurations are set to a matching value, if in doubt use "standard   # not verified yet".
+
+3. We have test cases that verify each of the four options (with any binary/packed and DISPLAY USAGE, checking truncation for both the integer and decimal part [should be identical, but testing is better...]).
     

Log in to post a comment.

veeam logo