fbpx
× Visual Objects

Please use this forum to post questions about Visual Objects and Vulcan.NET

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

More
1 year 5 months ago #1 by Leonid
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:
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\0" (actually the third character is already addressed to area of memory outside allocated).

Best regards,
Leonid

Please Log in or Create an account to join the conversation.

More
1 year 5 months ago #2 by Karl Faller
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...

Please Log in or Create an account to join the conversation.

More
1 year 5 months ago - 1 year 5 months ago #3 by Leonid
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:
	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
Last edit: 1 year 5 months ago by Leonid.

Please Log in or Create an account to join the conversation.

More
1 year 5 months ago #4 by Karl Faller
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

Please Log in or Create an account to join the conversation.

More
1 year 5 months ago - 1 year 5 months ago #5 by Robert van der Hulst
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.

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.
Last edit: 1 year 5 months ago by Robert van der Hulst.

Please Log in or Create an account to join the conversation.

More
1 year 5 months ago #6 by Chris Pyrgas
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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
1 year 5 months ago #7 by Leonid
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

Please Log in or Create an account to join the conversation.

More
1 year 5 months ago #8 by Robert van der Hulst
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

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.