TIP: Using GFA's: 'MemCpy dst, src, cnt'...

[(X)]

When you want to copy a number or count of bytes: cnt from one memory location: src, to another: dst, using GFA's built-in: 'MemCpy dst, src, cnt' statement...

If, instead of the variable cnt, you use a literal: for example '9' or a constant: 'Const k = 9' the 'MemCpy dst, src, cnt' command works as expected.

If you use a variable such as: 'Dim cnt% = 9' or a function such as 'len(a$)', the source and destination are reversed from the specified order! 

Da! Da! Daaaaa!!!!!!!!!!!!!!!

It appears MemMove does not suffer from this anomaly.

$Library "gfawinx"
$Library "UpdateRT"
UpdateRuntime      ' Patches GfaWin23.Ocx
FullW 1
FontSize = 14
Win_1.OnTop = True

Local a$, b$

Print "Lets try copying the contents of a$ to b$ via memory copy command MemCpy..."
Print "The length or count of byte to copy can be specified by literal: '9' or"
Print "by function 'len(a$)' or Const 'Const k = 9' or variable 'Dim c% = 9'."

a$ = "GFA Basic", b$ = "123456789"
Print
Print "Before..."
Print "a$: "; a$, ", b$: "; b$
MemCpy V:b$, V:a$, 9
Print "Using a literal: '9': OK "
Print "a$: "; a$, ", b$: "; b$

a$ = "GFA Basic", b$ = "123456789"
Print
Print "Before..."
Print "a$: "; a$, ", b$: "; b$
Local lB% = Len(b$) 'Space(9)
Local Const k = 9
MemCpy V:b$, V:a$, k
Print "Using a Const:'k'.  This works as described."
Print "a$: "; a$, ", b$: "; b$

a$ = "GFA Basic", b$ = "123456789"
Print
Print "Before..."
Print "a$: "; a$, ", b$: "; b$
MemCpy V:b$, V:a$, lB
Print "Using a variable... FAILS: Copies in reverse order."
Print "a$: "; a$, ", b$: "; b$

a$ = "GFA Basic", b$ = "123456789"
Print
Print "Before..."
Print "a$: "; a$, ", b$: "; b$
MemCpy V:a$, V:b$, lB
Print "Using a variable... OK if src dst order reversed."
Print "a$: "; a$, ", b$: "; b$

a$ = "GFA Basic", b$ = "123456789"
Print
Print "Before..."
Print "a$: "; a$, ", b$: "; b$
MemCpy V:b$, V:a$, Len(b$)
Print "Using a function:'Len(b$)'... FAILS: Copies in reverse order."
Print "a$: "; a$, ", b$: "; b$

a$ = "GFA Basic", b$ = "123456789"
Print
Print "Before..."
Print "a$: "; a$, ", b$: "; b$
MemCpy V:a$, V:b$, Len(b$)
Print "Using(a, function) : 'Len(b$)' OK if src dst order reversed."
Print "a$: "; a$, ", b$: "; b$





[(X)]

The API CopyMemory works as expected in all modes...

from: binaryworld.net/Main/CodeDetail.aspx?CodeId=3593

Proc P_CopyMem()
 
 Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" ( _
   pDst As Any, _
   pSrc As Any, _
   ByVal ByteLen As Long)
 
 Local a$, b$
 
 Print "Lets try copying the contents of a$ to b$ via memory copy command MemCpy..."
 Print "The length or count of byte to copy can be specified by literal: '9' or"
 Print "by function 'len(a$)' or Const 'Const k = 9' or variable 'Dim c% = 9'."
 
 a$ = "GFA Basic", b$ = "123456789"
 Print
 Print "Before..."
 Print "a$: "; a$, ", b$: "; b$
 CopyMemory(ByVal V:b$, ByVal V:a$, 9)
 Print "Using a literal: '9': OK "
 Print "a$: "; a$, ", b$: "; b$
 
 a$ = "GFA Basic", b$ = "123456789"
 Print
 Print "Before..."
 Print "a$: "; a$, ", b$: "; b$
 Local lB% = Len(b$) 'Space(9)
 Local Const k = 9
 CopyMemory( ByVal V:b$, ByVal V:a$, k)
 Print "Using a Const:'k'.  This works as described."
 Print "a$: "; a$, ", b$: "; b$
 
 a$ = "GFA Basic", b$ = "123456789"
 Print
 Print "Before..."
 Print "a$: "; a$, ", b$: "; b$
 CopyMemory( ByVal V:b$, ByVal V:a$, lB)
 Print "Using a variable... OK."
 Print "a$: "; a$, ", b$: "; b$
 
 a$ = "GFA Basic", b$ = "123456789"
 Print
 Print "Before..."
 Print "a$: "; a$, ", b$: "; b$
 CopyMemory( ByVal V:b$, ByVal V:a$, Len(b$))
 Print "Using a function:'Len(b$)'... OK."
 Print "a$: "; a$, ", b$: "; b$
 
EndProc



You can declare the Sub like this and avoid including ByVal in the call.
 Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" ( _
   ByVal pDst As Long, _
   ByVal pSrc As Long, _
   ByVal ByteLen As Long)

[(X)]

I got this reply from the kind soul that manages the GFA help file.

You can send help file update and enquiries to: [e-mail]

The code supporting the MemCpy command in the OCX is very basic: in an older version, the source and destination addresses are loaded into to the esi and edi registers respectively, the memory block size into ecx, and then the data is copied across 8 bytes at a time (this would probably be for an older version of GFA as the memory blocks would have had to be of a multiple of 8); a newer version of the code is actually quicker and shorter, using the rep movsb assembly command to perform the copy operation – for this reason it is the fastest copy method available. In both instances, the movement of data from source (esi) to destination (edi) appears to be correctly implemented.

This is, sadly, as far as I can investigate into this matter as the error seems to stem from how the compiler sends the destination and source addresses to the OCX and I do not have access to the compiler code.

The following text in the help file may well explain why there is a difference: “MemCpy is one of the rare commands that is compiled inline when cnt is a constant (not a function).” – In other words, GFA uses two methods to compile this command, depending upon the form in which the count value is passed. The example text on the help page also highlights the problem you mention, but there is not a Known Issue noted (which means I picked it up back in 2014 when I mass converted the help file to HTML – all the example texts were tested and rewritten but the remaining text was copied over as it was - and I did not make a note to come back and add further text).

Just for information: if you are uncertain of whether memory blocks will overlap, you should always use MemMove rather than MemCpy – this seems to work correctly. Another item of information that you may find interesting is that GFA does not use Windows APIs to copy memory but implements the transfer using custom code.

I’ll pass this on to Sjouke and see if he has time to look into it; in the meantime, I will make a note to finally update the help page.

If you wish, I can also add a brief note to your forum post, unless you would like to do so.

[dragonjim]

Just to complete this thread: the error IS in the compiler and, as such, is not likely to be fixed any time soon.

Best advice is to use constants if you can, or used MemMove which is a better command anyway; or simply remember to reverse the source and destination if not using a constant.