Missing error trap

[John Petty]

PBWIN 8.03
The following code has a serious error

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.

[John Gleason]

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.

#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

[Michael Mattias]

According to my 8.03 help file, this...

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

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

[John Petty]

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

[John Petty]

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

[John Petty]

According to my 8.03 help file, this...

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

[Michael Mattias]

I gave up on DIM for arrays.

I always use..

 

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

[John Gleason]

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.

#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

[Michael Mattias]

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.

[John Petty]

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

#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

[StanHelton]

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

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

[John Petty]

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.

[John Gleason]

I agree with Stan above, and would like to add a comment about this:

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

[StanHelton]

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

[John Gleason]

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!

[John Petty]

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.

[StanHelton]

...
The proper solution is probably just correct documentation ...

I can agree with a documentation correction.

[Michael Mattias]

>I can agree with a documentation correction.

And an entry in the PowerBase Forum pending availability of said correction?

[Michael Mattias]

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

[Gösta H. Lovgren-2]

(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
===========================================