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* >> >
