Menu

#874 DISPLAY for variables with `P` picture may output one byte too much / leading zeroes

GC 3.x
closed
5 - default
2023-02-22
2023-02-20
No

Hi
May by a bug in display statement with P Picture
See the program attached

1 Attachments

Discussion

  • Simon Sobisch

    Simon Sobisch - 2023-02-20
    • labels: Display statement --> DISPLAY, pretty-display
    • summary: Bug in display statement with P picture --> pretty-display for variables with P picture
    • status: open --> accepted
    • assigned_to: Simon Sobisch
     
  • Simon Sobisch

    Simon Sobisch - 2023-02-20

    Yes, that's a bug on the DISPLAY side:

    • cob_display iterates over all real and internal fields via varargs
    • it gets both real field with their separate data-pointer ("01" for the first after MOVE, unchanged "00"for the second field) and attribute
    • those also get placed to pretty_display_numeric()
    • this does correctly setup a temporary field for display
    • the temporary field has a fixed data buffer, which is not zeroed after use (so may contain the last data)
    • the "internal numeric edited" second field is moved to the temporary one vie 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 the PICTURE (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 calculation

    I'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
  • Simon Sobisch

    Simon Sobisch - 2023-02-22
    • summary: pretty-display for variables with P picture --> DISPLAY for variables with P picture may output one byte too much / leading zeroes
    • status: accepted --> closed
     
  • Simon Sobisch

    Simon Sobisch - 2023-02-22

    Minimal reproducer of the original issue:

           IDENTIFICATION DIVISION.
           PROGRAM-ID. prog.
           DATA DIVISION.
           WORKING-STORAGE  SECTION.
           01 P1 PIC     999 value 1.
           01 P2 PIC     9P  value 0.
           PROCEDURE DIVISION .
               display '00=' P2 '; 001=' P1 '; 00=' P2 '.'
               GOBACK .
    

    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).

    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]


Log in to post a comment.