Incompatible indexing in case of access to PSZ bytes between VO and XSharp

[leon-ts]

Hello!

After porting of a test VO-application in XSharp the incompatibility in an indexing in case of access to PSZ variable bytes was found. In VO the indexing begins with 1, and in XSharp begins with 0 (it was clarified in the course of debugging). Though Visual Objects dialect is selected.

Example:

Code: Select all

LOCAL p AS PSZ
LOCAL i AS DWORD
LOCAL c AS STRING

p := MemAlloc(3)
MemCopyString(p, "abc", 3)

c := ""
FOR i := 1 UPTO 3
    c += CHR(p[i])
NEXT

In VO the variable c receives value "abc". In XSharp the variable c receives value "bc" (actually the third character is already addressed to area of memory outside allocated).

Best regards,
Leonid

[FFF]

Leonid,
indeed.
But,
...MemAlloc() allocates a memory buffer of at least <wBytes>... Since memory is allocated in increments of 32 bytes, some extra space may be allocated. For example, a request for even 1 byte will allocate 32 bytes.
...

If you e.g. change to i := 1 to 33
the result shows interesting garbage
Therefore, as Vo-help states:
...Notes: This function allows the direct manipulation of a memory location and should be used with extreme care. ...

What bothers me: even if i enhance the loop to e.g. 144, all the memory will be read, at least after the access above of the first 32 bytes i'd expect some warning/error, even from Vo runtime <g>. No wonder the world of C is fill of buffer overflows...

[leon-ts]

Karl,

The issue is not in allocating memory, but in indexing. My example in this form is written just to demonstrate the difference in PSZ indexing between VO and XSharp. As a result, after porting the output of the program differs.

If you are confused by the use of the example MemAlloc(), I can write this in a different way:

Code: Select all

	LOCAL i AS DWORD
	LOCAL c AS STRING
	LOCAL p AS PSZ
	LOCAL DIM p2[3] AS BYTE
	
	p := @p2
	MemCopyString(p, "abc", 3)

	c := ""
	FOR i := 1 UPTO 3
		c += CHR(p[i])
	NEXT

[FFF]

Leonid,
i understood the indexing, and yes, there's a problem/difference to Vo.

Usually i don't "touch" memory like this, so, by playing with your sample i was somewhat surprised, that there's nothing which hinders you, when coding faulty, to access "invalid" space - so i thought i'd mention this.

Karl

[robert]

Leonid,

Thanks for the report.
We will have a look at it and will see if we can fix it asap.
Probably needless to say that PSZ is only there for compatibility reasons. You should try to use standard .Net types when possible.

[Chris]

Hi Karl,

When you use pointers, then you can indeed create chaos (as all data memory is "valid" for pointers), this is why usage of pointers is completely depreciated in .Net. There's nothing that the compiler or runtime can do to protect you from this, apart from telling you not to use pointers

But in any case, of course when you are very careful pointers should still work, and the problem Leonid reported with PSZ indexing is a compiler bug, I'm sure Robert will be able to fix it.

Chris

[leon-ts]

Robert,

Thank you for answer!

Probably needless to say that PSZ is only there for compatibility reasons. You should try to use standard .Net types when possible.

Of course. It is matter only for ported code from VO.

Best regards,
Leonid

[robert]

Leonid,

I did a check in the compiler and found the cause of the problem. Will be fixed in the next build.

As a work around for this problem you can declare your local variable as BYTE PTR in stead of PSZ. That works as expected.

Robert