Re: [PATCH v2 2/2] ucrtbase: Hook up some functions with new names to existing implementations
Martin Storsjo martin@martin.st writes:
These are some functions that on a first glance seem to have a matching signature even though the exact symbol name isn't the same as in msvcr120.
It would be better to create a separate function, unless there is strong evidence that they are doing the exact same thing. For example, I expect that there's a reason for having both malloc and malloc_base; mapping them to the same function would make any difference hard to spot.
On Tue, 25 Aug 2015, Alexandre Julliard wrote:
Martin Storsjo martin@martin.st writes:
These are some functions that on a first glance seem to have a matching signature even though the exact symbol name isn't the same as in msvcr120.
It would be better to create a separate function, unless there is strong evidence that they are doing the exact same thing. For example, I expect that there's a reason for having both malloc and malloc_base; mapping them to the same function would make any difference hard to spot.
Hmm, yes. For the _base ones, it probably is good to use separate entry points to be able to differentiate properly between them.
The other cases in this patch are: - _crt_atexit, which possibly also deserves the same treatment - _set_app_type, which previously used to be called __set_app_type. Don't know if anything else has changed other than the number of underscores - _set_new_handler and _set_new_mode. In msvcr120, these had C++ signatures, now they are plain C functions
// Martin
Martin Storsjö martin@martin.st writes:
- _set_app_type, which previously used to be called
__set_app_type. Don't know if anything else has changed other than the number of underscores
- _set_new_handler and _set_new_mode. In msvcr120, these had C++
signatures, now they are plain C functions
These should be OK.
-
Alexandre Julliard -
Martin Storsjö