#40 Check PICTURE parsing

GC 2.2
closed
4
2017-04-10
2012-10-09
No

Discussion can be found at https://sourceforge.net/p/open-cobol/discussion/109660/thread/450dad37/

Zero-length is clearly a bug and should be fixed.
I'm thinking of issuing a warning for definitions like PIC 9(7)X(4).

Discussion

  • Bill Woodger

    Bill Woodger - 2012-10-10
        PIC 9(7)X(4).
    

    Is valid. I didn't choose such a good example as the above doesn't have much benefit as a definition beyond "documentation".

        PIC X(7)B(4)X(3).
    

    I have a 10-byte field which I want to output as seven, four blanks, three. If I miss off either of the X's or the B, I don't get the field I want, but I do get a clean compile.

    To "catch" those, I'd think at first of "(" not valid if preceded by ")".

    I believe that the "(0)" will get "chopped down" to "()" (or a valid commencement (as in it has not been rejected), with the closing parenthesis waiting to be processed next) as the leading zeros are removed. Within the existing code dealing, with the logical "()" as an error may suffice for that.

    A PIC must contain either A, X, Z, 9, currency-symbol, *, -. I will try to check later if this is exhaustive. In short, there must be at least one byte from the source field which can arrive in the target field - a PIC cannot just be "insertion editing" characters.

    There does appear to be some "cross-talk" in the coding. The length of the PICture clause seems able to affect the permitted length of the data-name (although the length of the data-name might not itself be what gets the syntax error). This can then also lead to the "expected LITERAL" message out of "nowhere".

    If someone is "in" the code, an expansion of the error message production would help, as might something like "character n in PICture clause" where n is the character that caused the message. I know that the latter is much more easily said than done, especially if the code is not working on a "copy" of the source line but a processed-version of the source line.

    For the more-experienced, an expansion of the error-messages is not such a big thing, but if a "newbie" is struggling to understand what they have done wrong out of 20 characters that they haven't quite got to grips with yet, it may put them off just getting a message "it's wrong".

     
    Last edit: Simon Sobisch 2014-01-10
  • Edward Hart

    Edward Hart - 2016-05-21
    • labels: parser --> parser, PIC
    • status: open --> closed
    • assigned_to: Edward Hart
    • Group: unclassified --> GC 2.0
    • Priority: 1 --> 1 - highest
     
  • Edward Hart

    Edward Hart - 2016-05-21

    Fixed in [r886].

     

    Related

    Commit: [r886]

  • Simon Sobisch

    Simon Sobisch - 2016-06-12
    • status: closed --> pending
    • Priority: 1 - highest --> 4
     
  • Simon Sobisch

    Simon Sobisch - 2016-06-12

    Edward, can you please verify that the following rule is checked (I think this applies to all COBOL compilers but I didn't checked)?

    Each ofthe symbols from the set ‘CR’, 'DB‘, 'E', 'S', 'V', may appear only once

     
    • Edward Hart

      Edward Hart - 2016-06-12

      Done: everything working fine except when multiple S's are next to each other. It's now fixed in [r916].

       

      Related

      Commit: [r916]

      • Simon Sobisch

        Simon Sobisch - 2016-06-12

        Thank you. What do you think of a different message like "only one %s symbol allowed in PICTURE string" leading to only one error message for ss9s?

         
        • Edward Hart

          Edward Hart - 2016-06-12

          What do you think of a different message like "only one %s symbol allowed in PICTURE string" leading to only one error message for ss9s?

          Sounds good; I've added it in [r917].

           

          Related

          Commit: [r917]

  • Edward Hart

    Edward Hart - 2016-06-12
    • status: pending --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks