The address of the string can now be established, and passed to the procedure. So providing strings themselves are not used in the procedure, you should remain safe.
Another hazard can be encountered if you try to POKE values straight into a string.
Try
E> A$="123456789": Rem Define a string of characters For C=0 To Len(A$)-1 AD=Varptr(A$) : Rem Get the address V=Peek(AD+C) : Rem Get Ascii value of current element Poke AD+C,V+1 : Rem Add 1 to it Next C Print A$
When you return to the Editor, you will discover that your listing has been changed!- AMOS Professional is trying to save space by storing your string in the program listing, rather than the standard variable "buffer". This problem can be solved by loading the first character into the start of the string, then adding the remaining characters later. Here is how:
E> A$="1" : Rem Set up the first character A$=A$+"23456789" : Rem Now add remaining characters
This fools AMOS Professional into creating a separate copy of the string in the variable buffer.
Numerical arrays are stored as a simple list of values, with each dimension stored in turn. Look at the following array:
X> Dim TEST(3,3)
That array is held in the following order:
0,0 0,1 0,2 0,3 1,0 1,1 1,2 1,3 2,0 2,1 2,2 2,3 3,0 3,1 3,2 3,3
So to return the address of the first value of the array, you would use this:
X> Varptr TEST(0,0)
String arrays are more complex, because their length needs to change whenever one of their elements is assigned to a new value. The only way of ensuring total safety is to avoid them altogether! If you ignore this advice and try to access them using VARPTR, you are risking real danger.