@BRL - request: String indexing boundary checks

Hi,

try this code:

Strict
Framework brl.blitz

Local Text$ = "Text"
WriteStdout Text [ -5 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ -4 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ -3 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ -2 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ -1 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 0 ] + "~n" 'Ok, returns: 84  -> T
WriteStdout Text [ 1 ] + "~n" 'Ok, returns: 101 -> e
WriteStdout Text [ 2 ] + "~n" 'Ok, returns: 120 -> x
WriteStdout Text [ 3 ] + "~n" 'Ok, returns: 116 -> t
WriteStdout Text [ 4 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 5 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 6 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 7 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 8 ] + "~n" 'Danger of undefined results!

Currently it seems to be possible in BlitzMax to access any memory location just by indexing a string. There's no boundary check (like with arrays). I don't like this, since this could be the source of some wired and hardly findable bugs. It is just a lack of security when programming. Could you please add a some code which checks whether the index is smaller than zero or greather or equal to the string size, and then throws an "Index out of bounds!" exception?

Wouldn't it be easier just using the functionality that is officially in for :String instead of using hack approaches like [x] on them?
I'm aware that they work, but its up to you to take care that you are not doing some crap actually.

Just use index 0 .. string.length-1 and you won't have problems. (ie write yourself set - get functions that throw errors if you try to do unallowed access)

Simple reason is, that actually index -4 and -8 have their own needs on objects (what you see above is no string specific behavior) and removing that until the stuff behind it is actually exposed to the users would be a very bad idea, at least out of my sight.

I would think this is a bug.

Strings should atleast have boundry checks in DEBUG mode, as with Arrays.

Why?
String is no array object. The [x] approach only works because you jump around on the actual objects memory.
It is no string thing that you can use [x] to get the characters within the string. (beside that: using that way you break UTF)

If you need a character array, use one or create something similar to StringStreams in other language (you could use a TBank as well).
String is no character array as in C / C++

A more robust/consistant language?

Ive been going over the asm output and all i can see is a call to _brl_blitz_ArrayBoundsError when indexing arrays in debug mode.

But i allso seem to remember mark saying something about String indexing being a big hack, so im not going to argue ;)

Maybe this is something to hope for in the eventual rewrite of the blitzmax compiler =) hehe

I agree with Dream, what Fabian is doing is in fact a "Hack", of which I am quite happy to use. However because it is a hack it has the advantage of non of the boundary Checks being made, and is therefore faster.

If you cannot keep track of the boundary yourslf use :string, if you can and you want the speed advantage of the system not keep track of boundary then use string/array

??? What does this mean? Is this valid BlitzMax code?

Strict
Framework brl.blitz

Import brl.linkedlist

Local Text:TList = CreateList ( )
WriteStdout Text [ -5 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ -4 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ -3 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ -2 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ -1 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 0 ] + "~n" 'Ok, returns: 84  -> T
WriteStdout Text [ 1 ] + "~n" 'Ok, returns: 101 -> e
WriteStdout Text [ 2 ] + "~n" 'Ok, returns: 120 -> x
WriteStdout Text [ 3 ] + "~n" 'Ok, returns: 116 -> t
WriteStdout Text [ 4 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 5 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 6 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 7 ] + "~n" 'Danger of undefined results!
WriteStdout Text [ 8 ] + "~n" 'Danger of undefined results!

You can only index arrays, strings and pointers (as far as I know).This almost sounds like I want to remove this memory? I just want that you aren't able to access the memory by indexing. The C code, which of course needs to access to the "class" and "refs" fields (index -4 and index -8 are not the actual names) of the object won't be effected by this.Yes, that's right, however, you'll see that strings and arrays have some things in common: both have a "changing object size" (that means that different instanced of the same class can have different sizes), both are hard coded in the bcc, both are sorted collections, both can be sliced, both can be indexed. It isn't that strange to expect that both have the same security checks.

However I'm currently thinking you muddle something up: Are you aware of the difference between

Local Text$ = "Text"
WriteStdout Text [ 3 ] + "~n"

and

Local Text$ = "Text"
WriteStdout ( ( Short Ptr Byte Ptr Object Text + 2 ) [ 3 ] + "~n" )

?
Although it is doing the same it is different: The first one directly indexes the string, so this is nearly the same like indexing an array. The second one does first convert the string object to a pointer, and then indexes the pointer. This of course should never be checked, since it is simply impossible to define the boundaries of a pointer. The second one could be called a "hack", because if you're doing this way you can get really strange results as soon as you just one time aren't 100% aware of what you're doing.Indexing an array is the same "hack" as indexing a string.Actually I thought the same (so Dream's answer really surprised me); I just had a gut feeling saying me it would be better to post this as request...

I'm with Fabian, and laugh at the usage of the term "hack". No pun intended.
If that's a hack, and the current implementation may very well be one, then you should really be requesting for "dehacking" it. There is no reason why the [] operator when applied to strings couldn't perform bounds checking in debug mode. The compiler knows very well the type of the expression to which any operator is applied, so what's the problem really? It's applied to a pointer expression, OK let's just access the said memory area. It's applied to a string, OK let's perfoem some bounds checkings.

Erm the -4 and -8 access is not only important to the C code but to many BM programmers as well.

As mentioned above: if you want to have your boundary safe access use functions. Here is the code if you want it :)

function WriteByteToString(str:String, val:Byte, index:int)
   if index < 0 or index >= str.length Throw "Access out of boundary on string " + str
   str[index] = val
end function


function ReadByteFromString:Byte(str:String, index:int)
   if index < 0 or index >= str.length Throw "Access out of boundary on string " + str
   return str[index]
end function

I don't see a reason all should suffer with slower speeddue to stuff that is not officially in and that is only needed by programmers not taking care of what they actually do. (its not like string access is that high dynamic that you can not check for boundaries yourself, right)

It wont be slower if you apply the same rules as for Arrays.

Bounds check in DEBUG mode only.

Dreamora, I think grable just reminded you a basic principle: actualy read the posts you're responding to :)

I'm sorry, but could you please post some code showing this usage? Maybe you're talking about this:

Strict
Framework brl.blitz

Global Obj:TType = New TType
Local Pointer:Byte Ptr

Pointer = Byte Ptr Obj - 4 'access the object's reference counter

Local IntPtr Ptr = Int Ptr Pointer
WriteStdout "Object has " + ( IntPtr [ 0 ] & $7FFFFFFF ) + " reference(s)~n"

Pointer = Byte Ptr Obj - 8 'access the object's class

IntPtr = Int Ptr Pointer
WriteStdout "The class struct of the object's class is located at memory address " + IntPtr [ 0 ] + "~n"

Type TType
EndType

However the boundaries I request won't effect that code at all. The code above is indexing pointers, but I just want to have boundaries when indexing strings (and also only in debug mode).

P.S.: The code you posted above is not valid BMX-code, since you're trying to write to strings, however, once created, a string cannot be changed any more.

The string indexing boundary check thing is definitely a BUG!

Oh sorry, therefore I posted to the wrong forum :-)
But thanks a lot for declaring it's a bug!