#877 move from binary-c-long to comp-3 ignores implied decial point

[Denis HUGONNARD-ROCHE]

Seems that move from binary-c-long to comp-3 doesn't work

when i move a variable that type is binary-c-long and value 1 to a s(09)V99 COMP -3 variable the comp-3 variable contains 000000000.01

See attached program
Denis.

[Denis HUGONNARD-ROCHE]

move to comp-3 instead of comp-2 in the title

[Simon Sobisch]

With dear respect: I have no idea what this is about, please try to create better issues than "doesn't work".

Starting with: What is the problem here?

Note: the result with cobc -xj test.cob is identical between GC2.2 and GC 3.2rc2, but other than that I can't test anything without a clear report / test sample.

[Denis HUGONNARD-ROCHE]

Sorry if it is not clear ...
i modified the program ...

[Vincent (Bryan) Coen]

I have changed the code to provide a pic z(8)9.99- field.
after each move then moved target to display fld and displayed it and this is result .

./test
1.00
1.00
1.00
0.01
1.00
+000000000.01

Looks good to me.

You should NOT try and display a binary field as GC does not convert to display format (char) prior to the display :)

Or in other words - bad Cobol.

[Denis HUGONNARD-ROCHE]

sorry again i forgot to post the modified test ...
is it normal that when i move a variable that type is binary-c-long and value 1 to a s(09)V99 COMP -3 variable the comp-3 variable contains 000000000.01

[Simon Sobisch]

when i move a variable that type is binary-c-long and value 1 to a s(09)V99 COMP -3 variable the comp-3 variable contains 000000000.01

That is of course bad and an error in GnuCOBOL, I'll investigate in depth after the other issue.

[Denis HUGONNARD-ROCHE]

Hi Vincent
I don't know if it's good or bad cobol ;-)
I currently try to extend the move statement test cases
This move from binary-c-long to comp-3 is allowed in the code .
So i wrote a test for this case.
Note that if you change the destination field with a display type , it works

[Vincent (Bryan) Coen]

Correct and that is the way it has to be done to display or print such a
result.
i.e., the filed must be in edited form.

GC is not unique in this regard see your Cobol programming book.

Note that some compilers will convert it for you but this is rare as a
compiler is NOT a mind reader.
You must allow for typecasting when doing such and that also applies to
doing arithmetic such as using COMPUTE i.,e  allowing for truncation or
rounding etc.

See the extra options on it.

The issue with 00.01 on a result is more than likely due to misuse of
the decimal point or implied point as the -c-long is not using such but
allowed for that I would have thought that it would be treated as whole
numbers.
I inly spotted it after posting and did not look at my coding changes -
I had only allowed 5 minutes to play with it in between working on real
programs - when waiting for a compile or 50.

If you get errors of this type again automatically ASSUME that you made
a mistake and not the compiler.

That is not bullet proof but it will most likely be the programmers mistake.

On 21/02/2023 16:54, Denis HUGONNARD-ROCHE wrote:

Hi Vincent
I don't know if it's good or bad cobol ;-)
I currently try to extend the move statement test cases
This move from binary-c-long to comp-3 is allowed in the code .
So i wrote a test for this case.
Note that if you change the destination field with a display type , it
works

[Simon Sobisch]

As noted before - this is an error that got in after GC 3.2 RC1 and before RC2.
It also wasn't fixed "locally" in 3.x when tested yesterday, so I've started working on it (now having a complete testcase).

Checking the details shows [r4975] to have introduced that (around line 1398), it applies to any MOVE from any binary type to any packed. where the source has no decimal point, but the target has.

Additional issues exists (likely existed longer) when there is one or more trailing P in the PICTURE clause; I'm fixing both together.

Much more issues exist with leading P in the PICTURE clause (for all USAGEs) which won't get fixed for GC 3.2. These are solved with 4.x as it needs a codegen change and several adjustments in the runtime, which need several testsuite entries .

[Simon Sobisch]

Short update: after doing a bunch of updates to MOVE (and to the arithmetic storing of fields) this one is solved - output of the test program above (one round of -1 to field-02 added) with those changes (still have to finish some pieces, will then commit):

+00000000000000000001
+000000001.00
-00000000000000000001
-000000001.00
00000000000000000001
+000000001.00
00000000000000000001
+000000001.00

[Simon Sobisch]

Works with the current SVN version (same result as it had with 2.2 btw), so closed. In the case that you still find anything "open", just drop a note and we can reopen it.