[RESOLVED] Trimming Nulls with SysReAllocString

Hi! Can anybody please confirm that trimming null characters from a string using the function SysReAllocString is without any undesirable side-effect(s) such as memory leaks, etc.? MSDN has the following warning on the SysReAllocString function:

Quote:

---

The address passed in psz cannot be part of the string passed in pbstr, or unexpected results may occur.

---

Here is a sample usage:

Code:

---

Private Declare Function SysReAllocString Lib "oleaut32.dll" (ByVal pBSTR As Long, Optional ByVal pszStrPtr As Long) As Long

Dim sTemp As String
sTemp = Space$(1048576)  '1 MB
Mid$(sTemp, 2&) = vbNullChar

'This function allocates a new string,
'copies the passed null-terminated string into it
'and then deallocates the old contents
Debug.Print CBool(SysReAllocString(VarPtr(sTemp), StrPtr(sTemp)))
Debug.Print Len(sTemp)    'prints 1

'This has the same effect as sTemp = vbNullString
SysReAllocString VarPtr(sTemp)
Debug.Print StrPtr(sTemp)    'prints 0

---

I hope somebody can shed light on this... :confused:

I wouldn't do that if I were you. The article explicitly warns against doing that. That API is not equipped to handle overlapping BSTR buffers(BSTR buffers shouldn't overlap anyway) so while it may work most times, sooner or later you're probably going to get an access violation error or more likely(and worst) your application just crashes with no error. I've experienced this sort of thing using APIs like that badly.

May I ask what you are really trying to do here ?

I thought so too. However, in the related function SysReAllocStringLen, there is no warning that you cannot pass the same string in the psz parameter. Even in the documentations for the Windows CE .NET, Windows CE 3.0, Windows Mobile 6.5 and Windows Embedded Compact 7 versions of SysReAllocString, there are no mention of that particular situation. Perhaps the documentation is outdated. MSDN docs are not completely reliable IMHO.

I've done some inconclusive tests on these two functions trying to detect any memory leak and so far, they have not failed outright. The tests I did consists of monitoring the test program's memory usage in Task Manager and keeping track of the variable's VarPtr, StrPtr and Len while doing repeated string allocation/deallocation using those two functions. The results I got were confusing. For instance, while looping through the sequence of allocation/deallocation, the program's memory usage increased continuously up until a few rounds, and from there, it remained stable no matter how long I repeated the test. Also, during the initial rounds, StrPtr(strVar) changed addresses, but after a while, remained fixed on one memory location. VarPtr(strVar) never changed address, probably due to having been declared at the module-level. The value of Len(strVar) meanwhile, was being returned as expected. The strVar was repeatedly allocated 1 MB of space characters, for a total of 2 MB bytes (not including the length field and terminating null) so as to ensure it was not being cached and for quickly identifying possible leaks.

From what I can deduce from MSDN's inadequate documentation, SysReAllocString does the following steps:

1. Determine the size of the passed wide string by counting the number of characters up until the first null character.
2. Allocate a block of memory with that size (0 if NULL string was passed).
3. Copy the passed null-terminated string into the allocated memory and then append a null character.
4. Free the old string.
5. Make the pbstr parameter point to the newly allocated string (or 0 if NULL string was passed).

SysReAllocStringLen seemingly follows similar steps, with the exception of obtaining the size from the supplied parameter.

If SysReAllocString works as I understand, then it should be able to trim a typical null-terminated string buffer returned from an API call. It would be a superior alternative to LeftB$(sBuffer, InStrB(sBuffer, vbNullChar)) or even to Left$(sBuffer, lstrlen(sBuffer)). That is, if it works without leaking memory...

Well to be fair, I've experienced the MSDN Docs on BSTR functions being inconsistent with my own observations in the past. In my case it was SysAllocStringByteLen. If all your tests proves it to be stable then by all means proceed. Memory leaks and crashes are the two main concerns and as you implied, you haven't experienced either problems. COM and OLE are very complicated technologies and its good to always test regardless of what the DOCs say.....sometimes they can be misleading.

Indeed, MSDN docs can be quite confusing. In the meantime, I'm using the following wrapper function that addresses the caveat given by MSDN:

Code:

---

Public Function TrimNull(ByRef StringZ As String) As String
    SysReAllocString VarPtr(TrimNull), StrPtr(StringZ)
End Function

---