Am Freitag, den 09.10.2009, 15:44 +0200 schrieb Alexandre Julliard:
If the test case is based on observing internal behavior that's not acceptable either. Even if someone else fixes it, the test would force the fixer to replicate internal details.
Hi,
I can see all of your concerns and the message of what not to do is understood. If my enthusiasm to reveal the reason for the error got me too far I'm sorry and this is my official excuse. I'll try to rewind any knowledge to the point where it all started.
And that was here:
The original goal of my journey was to understand why BSTR memory structures constantly survived a SysFree cycle in Windows while they got overwritten for some case in Wine. From what I read in bugzilla the argumentation always explained, that this comes from heap management. The tip to solve this with native oleaut, further links to MSDN documentation about SetOaNoCache() and the KB article http://support.microsoft.com/kb/937360 led the way that heap was not freed upon calling SysFreeString.
With this bit of knowledge I ask if the following testcase will be valid. It should not care about any code inside the "black box":
... for (i=10;i<100;i++) { s1 = SysAllocStringLen(sz128,i); SysFreeString(s1);
HeapAlloc(GetProcessHeap(),0,10);
s2 = SysAllocStringLen(sz128,i); SysFreeString(s1); ok(s1==s2, "got a new memory address\n"); } ...
The only development goal this testcase has, is to request a function that provides the same memory address in two subsequent Alloc/Dealloc calls with the same string size. Noone should be forced to implement something that goes anywhere close to native implementation.
A start maybe.