Hi Jacek,
Jacek Caban jacek@codeweavers.com wrote:
On 4/25/22 13:50, Dmitry Timoshkov wrote:
diff --git a/dlls/ieframe/ieframe.h b/dlls/ieframe/ieframe.h index 633906a70ca..1bae1f6781d 100644 --- a/dlls/ieframe/ieframe.h +++ b/dlls/ieframe/ieframe.h @@ -340,6 +340,11 @@ static inline void unlock_module(void) { InterlockedDecrement(&module_ref); }
+static inline void * __WINE_ALLOC_SIZE(2) heap_realloc_zero(void *mem, SIZE_T len) +{
- return HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, mem, len);
+}
I think it would be better to use CRT memory allocators in ieframe instead of heap functions directly. Once we do that, there is no CRT counterpart to zeroing realloc.
I agree that moving to using CRT is the way to go, however that would probably make the fix more intrusive than necessary, so I decided to create a simpler patch.
In this case, it seems to me that we'd want to initialize the entry when it becomes accessible, not necessarily on allocation.
I'm not sure I understand what you mean by entry being made accessible, could you please clarify? As far I can see from the ieframe code inspection IWebBrowser::GoForward()/IWebBrowser::GoBack() directly call helpers that rely on log entries being already intialized, and the only place where a log entry gets intialized is dochost.c,update_travellog().