Announcement

Collapse
No announcement yet.

Missing error trap

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Missing error trap

    PBWIN 8.03
    The following code has a serious error
    Code:
    SUB Whatever()
        LOCAL Split() AS STRING
        LOCAL InText(1) AS STRING
        LOCAL PCnt AS LONG
        LOCAL x AS LONG
        Intext(0) = "a,b,c"
        Intext(1) = "a,b,c,d,e,f"
        FOR x = 0 TO UBOUND(Intext)
            PCnt = PARSECOUNT InText(x)
            DIM Split(PCnt - 1)
            PARSE InText(x), Split()
        NEXT
    END SUB
    As stated in the manual the second time the loop encounters the DIM statement it will ignore it without an error. The PARSE statement however does not even require a pre dimensioned array but it is “advantageous”. On the second pass through the FOR loop the PARSE does not increase the size to fit the number of parsed strings nor does it give an error 9 in the debugger.

  • #2
    Using ver. 8.04 (but I doubt that makes a difference)
    I compiled the below code just to make an extreme case, and I believe no error is generated because the PARSE statement default behavior stops at the allocated size of its destination array. IMHO it's a valuable safety measure.

    Code:
    #COMPILE EXE
    #DIM ALL
    
    FUNCTION PBMAIN () AS LONG
    
      CALL whatever
    
    END FUNCTION
    
    SUB Whatever()
        LOCAL Split() AS STRING
        DIM InText(1) AS STRING
        LOCAL PCnt AS LONG
        LOCAL x AS LONG
        Intext(0) = "a,b,c"
        Intext(1) = REPEAT$(10000, "a,b,c,d,e,f")
        FOR x = 0 TO UBOUND(Intext)
            PCnt = PARSECOUNT (InText(x))
            DIM Split(PCnt - 1)
            PARSE InText(x), Split()
        NEXT
    END SUB

    Comment


    • #3
      According to my 8.03 help file, this...
      Code:
      LOCAL InText(1) AS STRING
      .. should not have been accepted.

      Under LOCAL .....
      To declare an array as a local variable, use an empty set of parentheses in the variable list: You can then use the DIM statement to dimension the array
      Your parens are not empty.

      But let's say that is OK, you still are assigning values...
      Code:
      Intext(0) = "a,b,c"
      Intext(1) = REPEAT$(10000, "a,b,c,d,e,f")
      .. to an array you have not DIM'd or REDIM'd. Those statements should be returning an error. But you are not checking, so you don't know.

      MCM
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        Not really John as if you use the parsecount to address the array later in the program then you get GPF's or the error 9 in the debugger which is of course not where the acual error occured. Note that using DIM rather than REDIM is straight out of the manual, which DOES NOTstate that PARSE will terminate if the receiving array is not large enough, in fact the opposite in that it will build an array large enough to fit the parse results without any warning that it cannot do this for a pre DIMed array

        Comment


        • #5
          Sorry Micheal but you have missed the point due to the poor example I gave. In my real program that had the problem (silly mistake on my part) the sub was passed a valid array of strings. The problem is the Split array not being correctly sized or giving an error by PARSE even in the debugger.
          PS you are mixing two different code examples mine and John Gleason's who correctly fixed the DIM for the InText array
          Last edited by John Petty; 18 Jun 2008, 01:48 PM.

          Comment


          • #6
            Originally posted by Michael Mattias View Post
            According to my 8.03 help file, this...
            Code:
            LOCAL InText(1) AS STRING
            .. should not have been accepted.

            Under LOCAL .....


            Your parens are not empty.
            Actually Micheal I think you have picked up an error in the manual. If you only look at the Split array you will see I did exactly what the manual specified, ie LOCAL with empty parentheses and then DIM it but of course this caused the problem as it needed to be REDIM inside the FOR loop which the manual doesn't give as an option

            Comment


            • #7
              I gave up on DIM for arrays.

              I always use..
              Code:
               
              
              FUNCTION whatever
                 LOCAL  X() AS something     
              
                  ....
                 .....
                  REDIM X(number)
              Never have any problems with this kind of thing.

              But I cannot find where LOCAL INtext(1) AS STRING creates a two-element array. I would have to test that, but I'd go even money Intext() is not an array 'immediately' at entry to the procedure.


              MCM
              Michael Mattias
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                John, do you have an example you can post showing the error/GPF? I ran the below code and got no ERR code in the debugger, or GPF running the EXE.
                Code:
                #COMPILE EXE
                #DIM ALL
                
                FUNCTION PBMAIN () AS LONG
                
                  CALL whatever
                
                END FUNCTION
                
                SUB Whatever()
                    LOCAL Split() AS STRING
                    DIM InText(1) AS STRING
                    LOCAL PCnt AS LONG
                    LOCAL x AS LONG
                    Intext(0) = "a,b,c"
                    Intext(1) = REPEAT$(10000, "a,b,c,d,e,f")
                    FOR x = 0 TO UBOUND(Intext)
                        PCnt = PARSECOUNT (InText(x))
                        DIM Split(PCnt - 1)
                        PARSE InText(x), Split()
                    NEXT
                        PCnt = PARSECOUNT (InText(1))
                        
                    Intext(0) = REPEAT$(10000, "a,b,c,d,e,f")
                    Intext(1) = REPEAT$(10000, "a,b,c")
                        PCnt = PARSECOUNT (InText(0))
                        PCnt = PARSECOUNT (InText(1))
                        PARSE InText(1), Split()
                        PARSE InText(0), Split()
                        PCnt = PARSECOUNT (InText(0))
                        PCnt = PARSECOUNT (InText(1))
                        
                    ? "done"
                END SUB

                Comment


                • #9
                  That last code should not have an error as you have changed...

                  LOCAL InText(1) AS STRING

                  to

                  DIM InText(1) AS STRING


                  DIM for arrays is an executed statement.
                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    John the error occurs when you try to use the Split array assuming PARSE worked correctly as it doesn't give an error message even in the debugger. In the following example when run in the debugger will give error 9 when x = 1 and y = 3
                    Code:
                    #COMPILE EXE
                    #DIM ALL
                    
                    FUNCTION PBMAIN () AS LONG
                    
                      CALL whatever
                    
                    END FUNCTION
                    
                    SUB Whatever()
                        LOCAL Split() AS STRING
                        DIM InText(1) AS STRING
                        LOCAL PCnt AS LONG
                        LOCAL x AS LONG
                        LOCAL y AS LONG
                        LOCAL Test AS STRING
                        Intext(0) = "a,b,c"
                        Intext(1) = "a,b,c,d,e,f"
                        FOR x = 0 TO UBOUND(Intext)
                            PCnt = PARSECOUNT (InText(x))
                            DIM Split(PCnt - 1)
                            PARSE InText(x), Split()
                            FOR y = 0 TO pcnt - 1
                                Test = Split(y)
                            NEXT
                        NEXT
                    
                        ? "done"
                    END SUB

                    Comment


                    • #11
                      Originally posted by John Petty View Post
                      John the error occurs when you try to use the Split array assuming PARSE worked correctly as it doesn't give an error message even in the debugger. In the following example when run in the debugger will give error 9 when x = 1 and y = 3


                      Code:
                      ...
                                DIM Split(PCnt - 1)
                      ...
                      From the manual:
                      Array Initialization and Absolute Arrays
                      PowerBASIC generates an error message when it encounters an array that hasn't been dimensioned. If the array has already been dimensioned, the DIM statement is ignored. A new array is not created and a run-time error is not generated.
                      Use REDIM instead to insure that you have a dynamic array. In the example, Split() is never resized to the larger number of elements. Split(3) will never be a valid element.


                      Stan
                      Last edited by StanHelton; 19 Jun 2008, 09:31 AM. Reason: expand explanation
                      Do not go quiet into that good night,
                      ... Rage, rage against the dark.

                      Comment


                      • #12
                        Originally posted by StanHelton View Post
                        From the manual:
                        Use REDIM instead to insure that you have a dynamic array. In the example, Split() is never resized to the larger number of elements. Split(3) will never be a valid element.


                        Stan
                        Stan if you read my original post you will see I quoted that. The point
                        of the post is that the PARSE must check the array and know that to complete it would have to address an array out of bounds or redim it as implied in the manual under PARSE so at least in the debugger it should report error 9.
                        The subject of the post is MISSING ERROR CHECK, not what is the error, as I stated the code has a serious error and it was the DIM.

                        Micheal read the posts, yes I made a mistake in the example code, fortunately John Gleeson picked it up and fixed it without comment, so if you can add something useful forget that code and run the final sample which illustrates what the post is about.

                        Comment


                        • #13
                          I agree with Stan above, and would like to add a comment about this:
                          Originally posted by John Petty View Post
                          ...the manual, which DOES NOTstate that PARSE will terminate if the receiving array is not large enough, in fact the opposite in that it will build an array large enough to fit the parse results without any warning that it cannot do this for a pre DIMed array
                          True, the docs do not state that PARSE will terminate if the receiving array is not large enough--that was my hypothesis--and if true, maybe it would make a good addition to the docs. However, I am highly certain that PARSE will not dimension the array automatically to fit the results, and this could be a key point here. The docs say:
                          It is usually advantageous to dimension array$ to the correct size with the use of the PARSECOUNT function. The PARSE statement is typically much more efficient, as a whole, than repeated use of the PARSE$ function when it is necessary to parse an entire string expression.
                          Here's where the question may arise, "Does the second sentence PARSE statement refer back to being efficient dimensioning the array$ from the first sentence?" And in a way, it looks like yes it does. But I think (as of this writing ) it's basically saying that if you don't use PARSECOUNT, you must use another method to dimension the array big enough to be sure you get the whole string parsed.

                          Comment


                          • #14
                            Originally posted by John Petty View Post
                            Stan if you read my original post you will see I quoted that. The point
                            of the post is that the PARSE must check the array and know that to complete it would have to address an array out of bounds or redim it as implied in the manual under PARSE so at least in the debugger it should report error 9.
                            The subject of the post is MISSING ERROR CHECK, not what is the error, as I stated the code has a serious error and it was the DIM.

                            Micheal read the posts, yes I made a mistake in the example code, fortunately John Gleeson picked it up and fixed it without comment, so if you can add something useful forget that code and run the final sample which illustrates what the post is about.
                            John,

                            Ok, I RE-read all the posts in this thread and I compiled and ran the last code snippet. I also RE-read the PB manual on DIM, REDIM, PARSE, PARSE$, and PARSECOUNT.

                            The docs don't say PARSE will resize the target array. I don't see where it implies that PARSE will resize the target array. Perhaps they should change

                            "It is usually advantageous to dimension array$ to the correct size with the use of the PARSECOUNT function."

                            to

                            "Always dimension array$ to the correct size with the PARSECOUNT function or some other method."

                            I use these functions in my code all the time and I've never encountered a problem. I think PARSE is performing as advertised.

                            Stan
                            Do not go quiet into that good night,
                            ... Rage, rage against the dark.

                            Comment


                            • #15
                              John, (I should use JP for you and I'll be JG ) I just read your most recent post (it appeared when I posted mine), and would like to add if I understand correctly: As far as having an error generated if PARSE exceeds its destination array size at runtime (or at least in the debugger)? IMHO in the debugger it would be a fine item (feature request?); in an exe tho? I'm thinking no, because you found it in the debugger!

                              Comment


                              • #16
                                JG I also wouldn't like anything changed for standard exe code that might slow it down, though I think as a minimum the documentation needs a serious update.
                                Stan I can't agree the PARSE statement works as advertised, from the manual main statement of purpose "Parse an entire string and extract all delimited fields into an array." NOTE the words ENTIRE and ALL they have a very clear meaning. Nowhere does it make the statement that it will parse the number of elements that will fit in the array, thus it implies it will redim the array to fit ALL the fields. As it doesn't give an error it also means error 9 is not generated as advertised.
                                The proper solution is probably just correct documentation, after all if one sees comments like "If the array has already been dimensioned, the DIM statement is ignored. A new array is not created and a run-time error is not generated." then you would expect similar warnings for PARSE.

                                Comment


                                • #17
                                  Originally posted by John Petty View Post
                                  ...
                                  The proper solution is probably just correct documentation ...
                                  I can agree with a documentation correction.
                                  Do not go quiet into that good night,
                                  ... Rage, rage against the dark.

                                  Comment


                                  • #18
                                    >I can agree with a documentation correction.

                                    And an entry in the PowerBase Forum pending availability of said correction?
                                    Michael Mattias
                                    Tal Systems Inc. (retired)
                                    Racine WI USA
                                    [email protected]
                                    http://www.talsystems.com

                                    Comment


                                    • #19
                                      If, of course, officially verified.

                                      The problem with documentation errors is.... until you hear it officially, you don't really know if it's the documentation in error or the product itself which is in error, do you?

                                      i.e., Maybe the documentation IS in fact the way the product is supposed to work, but doesn't!

                                      Which is why my own definition of 'bug' is simply, "does not work as documented." Either there is an error in the documentation or there is an error in the product.... but there IS an error, somewhere!

                                      (PowerBASIC Inc. senior management and I do not agree on this definition.. at least we have not agreed on it since 1991).
                                      Last edited by Michael Mattias; 20 Jun 2008, 09:08 AM.
                                      Michael Mattias
                                      Tal Systems Inc. (retired)
                                      Racine WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        Originally posted by Michael Mattias View Post
                                        (PowerBASIC Inc. senior management and I do not agree on this definition.. at least we have not agreed on it since 1991).
                                        Off topic, but since you brought it up {grin}. Is there anyone else who has disagreed with you since 1991, M? Or with whom you have disagreed?

                                        Enquirying Minds want to know.

                                        ===========================================
                                        "Any intelligent fool
                                        can make things bigger and more complex...
                                        It takes a touch of genius
                                        and a lot of courage
                                        to move in the opposite direction."
                                        -- Albert Einstein
                                        ===========================================
                                        It's a pretty day. I hope you enjoy it.

                                        Gösta

                                        JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
                                        LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

                                        Comment

                                        Working...
                                        X