[Mono-devel-list] Re: [PATCH] Improper free of return-value string pointers from unmanagedcalls

[Chris Day]

Just as an FYI, Microsoft recommends [1] that any return or out
parameters for strings (char*, wchar_t*, etc) use an IntPtr then use
Marshal.PtrToString* [2] to copy it into managed land.  If the function
allocates the string it is then up to you to import a free() function
which you can call with the IntPtr to deallocate the string.

Chris

[1]
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=ON3LnWFHBHA.1868
%40tkmsftngp03
[2]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/h
tml/frlrfsystemruntimeinteropservicesmarshalclassptrtostringautotopic1.a
sp 

> -----Original Message-----
> From: Steven Brown [mailto:swbrown at ucsd.edu] 
> Sent: Friday, 11 June 2004 3:33 PM
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-devel-list] Re: [PATCH] Improper free of 
> return-value string pointers from unmanagedcalls
> 
> Marcus wrote:
> 
> > Freeing the string pointers is the appropriate behavior for .NET 
> > compatibility.
> 
> Could you give me a link to some docs that refer to that?  
> It's empirically untrue as far as I can tell, as I can 
> repeatedly call a method that dynamically allocates the 
> returned string like:
> 
> MEMEAT_API char *foo(void)
> {
> 	static char *str = "Hello there";
> 	static int i = 0;
> 	char *newstr = (char *) malloc(strlen(str) + 1);
> 	strcpy(newstr, str);
> 	printf("%i: %s\n", i++, newstr);
> 	return newstr;
> }
> 
> and if it was supposed to free the pointers, Microsoft's .NET 
> implementation isn't, as the above bloats the process.  The 
> alternative does not:
> 
> MEMEAT_API char *foo(void)
> {
> 	static char *str = "Hello there";
> 	static int i = 0;
> 	//char *newstr = (char *) malloc(strlen(str) + 1);
> 	//strcpy(newstr, str);
> 	printf("%i: %s\n", i++, str);
> 	return str;
> }
> 
> It doesn't make sense to free such a string pointer, as often 
> string pointers will be coming from .rodata and such.
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
>