Problems using the lstrcpy function

[HackerVlad]

Today, for the first time, I encountered problems when using the lstrcpy function to copy strings. Of course, you may not notice this right away, but under certain circumstances, using this feature leads to fatal crashes of the application, as I saw today.

The Microsoft documentation says: https://learn.microsoft.com/en-us/wi...nbase-lstrcpya
It says that in no case should you use this function, but instead use the StringCchCopyA function. I decided to follow Microsoft's advice, but I have not found anywhere a way to declare function StringCchCopyA in VB6. Who can recommend what? Or suggest another replacement function.

And the lstrcpyA function causes a lot of memory problems and fatal application crashes, and you may not notice it right away...

[HackerVlad]

There's something I can't understand at all strsafe.h is this a DLL library at all?

[HackerVlad]

I was able to safely copy the lines through function SysAllocStringByteLen without crashing (instead of the lstrcpyA function that causes the crash):

PutMem4 VarPtr(strOut), SysAllocStringByteLen(ptrStrIn, bytesLen)

[HackerVlad]

It seems to me that it is better to completely abandon functions lstrcpyA and lstrcpyW in all program codes, everywhere. What do you think? And what safe alternative would you suggest?

[HackerVlad]

I also noticed that it is easy to copy unicode strings using the SysReAllocStringLen function, but what if I need to copy ansi string? Why is there no such function for byte copying? That would be the SysReAllocStringByteLen function...

[HackerVlad]

Through my experiments, I seem to have found the best way to copy a byte-by-byte ANSI string.

bytesLen = lstrlenA(pszIn)
SysReAllocStringLen VarPtr(StrOut), pszIn, CLng(bytesLen / 2) + 1
StrOut = MidB$(StrOut, 1, bytesLen)

[HackerVlad]

As a result, I copied the strings immediately through the ansi to unicode conversion function.

Private Declare Function SHAnsiToUnicode Lib "shlwapi" (ByVal pszSrc As Long, ByVal pwszDst As Long, ByVal cwchBuf As Long) As Long

FileName = Space$(bytesLen)
SHAnsiToUnicode pFDI.psz1, StrPtr(FileName), bytesLen + 1

[HackerVlad]

The SHAnsiToUnicode function is best called by number, for compatibility with XP. That would be the correct declaration (by the way, I noticed that a lot of functions from the shlwapi.dll library have to be called by numbers, for compatibility with Windows XP):

Private Declare Function SHAnsiToUnicode Lib "shlwapi" Alias "#215" (ByVal pszSrc As Long, ByVal pwszDst As Long, ByVal cwchBuf As Long) As Long

P. S. By the way, I finally figured out the problem of the lstrcpyA function. It turns out that for its correct operation, for some reason, you need to allocate a buffer one byte more than necessary, now I managed to avoid fatal crashes, but I still don't like using the lstrcpyA function, since an extra empty symbol at the end is at least ugly...

[fafalone]

StringCchCopyA and the rest of strsafe.h are inline functions not exported from any DLL. You'd have to port the code yourself.

[HackerVlad]

It's a shame, then, that Microsoft strongly recommends using the StringCchCopyA function, but it's impossible to call it... Or is there a way?

[fafalone]

You could do like I did with the Interlocked* compiler intrinsics and create a DLL or for tB a static library using C++ wrapping them, then call that from VB/tB.

In C/C++ you can call them just by #include <strsafe.h>

[HackerVlad]

You could do like I did with the Interlocked* compiler intrinsics and create a DLL or for tB a static library using C++ wrapping them, then call that from VB/tB.

In C/C++ you can call them just by #include <strsafe.h>

You know that we don't like programming in C++. We love VB!

[HackerVlad]

Today I also learned about new functions for copying strings from the library SHLWAPI.DLL. These are the two functions of SHAnsiToAnsi and SHUnicodeToUnicode.

These are very rare functions, and I've never seen anyone use them on the Internet...
Now you can use SHAnsiToAnsi instead of lstrcpyA, and SHUnicodeToUnicode instead of lstrcpyW. The length of the string is set manually.

Private Declare Function SHAnsiToAnsi Lib "shlwapi" Alias "#345" (ByVal pszSrc As Long, ByVal pwszDst As Long, ByVal cchBuf As Long) As Long
Private Declare Function SHUnicodeToUnicode Lib "shlwapi" Alias "#346" (ByVal pszSrc As Long, ByVal pwszDst As Long, ByVal cwchBuf As Long) As Long

[Eduardo-]

Why don't you use RtlMoveMemory?

[HackerVlad]

Why don't you use RtlMoveMemory?

This can also be used, but it is not always convenient.

I also noticed that it is very convenient to use the SysReAllocString function, since you do not need to specify the length of the string.

[Eduardo-]

This can also be used, but it is not always convenient.

When it is not convenient?

[anycoder]

Have you tried StrCpyNW it guarantees that the copying will not exceed the indicated length, if the text is longer than the size of the Buffer the terminal null is placed at the end of the buffer.

[HackerVlad]

https://learn.microsoft.com/en-us/wi...lwapi-strcpynw

I haven't used this feature, but Microsoft tells us all never to use this feature at all. And the description says that the terminating zero is not always copied.

[HackerVlad]

When it is not convenient?

Well, I've come across such exceptional cases, it's hard to explain. I can only say that when copying via CopyMemory, you need to take care of copying vbNullChar yourself and write +1 in the code for the length of the copy, unlike other functions.

[Eduardo-]

Well, I've come across such exceptional cases, it's hard to explain. I can only say that when copying via CopyMemory, you need to take care of copying vbNullChar yourself and write +1 in the code for the length of the copy, unlike other functions.

So it doesn't seem like a big problem, right?