With every GC version tested (2.2+ up to 3.2rc2) that results in: 00=00; 001=001; 00=001. with -fpretty-display, which is the default and in 00=00; 001=001; 00=00. with -fno-pretty-display.
If there is any P after the data then it prints one byte too much "whatever is in the internal terminal buffer".
Extending the test showed that on the other hand -fno-pretty-display has another bug, it prints the amount of Ps as leading zeroes (so 100 in 9PP gets displayed as 001).
P
pictureYes, that's a bug on the
DISPLAY
side:cob_display
iterates over all real and internal fields via varargsMOVE
, unchanged "00"for the second field) and attributepretty_display_numeric()
cob_move_display_to_edited()
, which fills the data up to its digits (4)the issues here are:
cob_move_display_to_edited()
only stores data up to thePICTURE
(all pic should match the size of edited fields but in this case this isn't true)pretty_display_numeric()
only takes positives scales into account for the size calculationI'm working on a fix (along with refactoring to and use similar code as used in other places).
Last edit: Simon Sobisch 2023-02-20
P
picture --> DISPLAY for variables withP
picture may output one byte too much / leading zeroesMinimal reproducer of the original issue:
With every GC version tested (2.2+ up to 3.2rc2) that results in:
00=00; 001=001; 00=001.
with-fpretty-display
, which is the default and in00=00; 001=001; 00=00.
with-fno-pretty-display
.If there is any P after the data then it prints one byte too much "whatever is in the internal terminal buffer".
Extending the test showed that on the other hand
-fno-pretty-display
has another bug, it prints the amount of Ps as leading zeroes (so 100 in 9PP gets displayed as 001).Both fixed with [r4998].
Fair warning: there are a bunch of pending issues with P data fields, I even consider to explicit mark this PICTURE character as unfinished...
Related
Commit: [r4998]