Re: [PATCH v2 2/2] ucrtbase: Hook up some functions with new names to existing implementations
Martin Storsjo <martin(a)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. -- Alexandre Julliard julliard(a)winehq.org
On Tue, 25 Aug 2015, Alexandre Julliard wrote:
Martin Storsjo <martin(a)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(a)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 julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Martin Storsjö