Chaps, I have most of an answer to this question. The author of the C++ DLL
gave me a fresh one which uses CoTaskMemAlloc to create the byte array
containing a LPWSTR which is the return value of his function. On the
receiving C# side it looks like this:
[DllImport("foobar.dll", CallingConvention = CallingConvention.StdCall,
CharSet = CharSet.Unicode)]
[return: MarshalAs(UnmanagedType.LPWStr)]
static extern string FooCommand(string token, string cmd, string data);
This does in fact return a managed string which I can use normally. So it
all seems to work, but technically I have no proof that the interop
marshaller is freeing the buffer as this article
<https://limbioliong.wordpress.com/2011/06/16/returning-strings-from-a-c-api/>
claims it should.
This leads to a separate interesting question ... what tool(s) can I use to
get proof the buffer is being freed? Some memory profiler? This would be an
interesting an useful lesson in itself.
*Greg K*
On 24 October 2017 at 16:52, Bill McCarthy <bill.mccarthy.li...@live.com.au>
wrote:
> https://msdn.microsoft.com/en-us/library/xda6xzx7.aspx
>
>
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Greg Keogh
> *Sent:* Tuesday, 24 October 2017 4:50 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Marshalling strings
>
>
>
> This article: https://limbioliong.wordpress.com/2011/06/16/returning-
> strings-from-a-c-api/
>
>
>
> Hints that the interop marshaller takes ownership of the returned string
> and will delete the buffer. If this is true, then it's pretty smart and
> invalidates our concerns about a possible leak. I'm reading more and
> running some experiments -- *GK*
>
>
>
> On 24 October 2017 at 16:28, Tony McGee <tmcgee...@gmail.com> wrote:
>
> My understanding would be that either the caller allocated a large enough
> buffer and passes it to the library in which case the callee does a copy
> and doesn't need to worry about it
>
> -or- the callee keeps the pointer they've given out and expects the caller
> to pass it back to another function to do the free/dealloc.
>
>
>
> I believe there's standard functions for allocating things like BSTR's
> from the COM days (SysAllocString/SysFreeString) where the callee allocates
> and the caller is responsible for deallocation but passing out raw wchar_t
> pointers without agreeing on a deallocation method isnt great.
>
>
>
> On 24 Oct 2017 15:14, "Greg Keogh" <gfke...@gmail.com> wrote:
>
> Folks, my REST web service makes calls to C++ functions in a native DLL.
> The functions return wchar_t* which I marshal into a managed string.
>
>
>
> The author of the C++ code doesn't know when to free the buffer he's
> allocated for the string (neither do I). The very last statement in his
> function is return char_ptr, so the function ends and the buffer becomes a
> leak. I consume the pointer after his function ends, so when can he delete
> it?
>
>
>
> Is there some trick I'm forgetting? Or are we doing it the wrong way?
>
>
>
> *Greg K*
>
>
>
