On Fri, 6 Nov 2015, Piotr Caban wrote:
On 11/06/15 11:28, Martin Storsjo wrote:
int CDECL _callnewh(MSVCRT_size_t size) { + int ret = 0; + LOCK_HEAP; if(MSVCRT_new_handler) - (*MSVCRT_new_handler)(size); - return 0; + ret = (*MSVCRT_new_handler)(size); + UNLOCK_HEAP; + return ret; } It doesn't make sense to lock heap cs in this case. Native is not doing it (at least in case of msvcp90.dll).
Hmm, but wouldn't it risk a race with another thread doing set_new_handler then? OTOH I guess that's ok/expected? But there's a similar lock in MSVCRT_operator_new; should we do the same locking on the msvcp side instead then, or just skip it altogether?
The return value change looks almost correct - the function only returns 0 or 1.
Ok, so should I force the return value to 0 or 1 regardless of what the function returns? I.e. ret = (*MSVCRT_new_handler)(size) ? 1 : 0; (or !!), or should I just repost it without the locking? // Martin