mirror of
https://github.com/alliedmodders/metamod-source.git
synced 2025-12-07 02:18:30 +00:00
I love spreading misinformation
Turns out this isn't true. Yay! Less work for me :^)
This commit is contained in:
parent
916f4058bf
commit
6548671084
@ -854,24 +854,6 @@ namespace SourceHook
|
|||||||
META_RES prev_res;
|
META_RES prev_res;
|
||||||
META_RES cur_res;
|
META_RES cur_res;
|
||||||
|
|
||||||
// TODO: STL operator= invocations beyond here can invoke corrupt destructors.
|
|
||||||
// this can lead to memory corruption/uninitialized memory use,
|
|
||||||
// as the STL operator= will try to call the destructor on the uninitialized
|
|
||||||
// member. If we see any memory corruption during operator= or similar,
|
|
||||||
// then that means we need to fix this and actually initialize these variables.
|
|
||||||
//
|
|
||||||
// One idea is to use placement copy constructors here, where we tell C++
|
|
||||||
// to initialize these variables with a copy constructor from another type:
|
|
||||||
// new (&uninitialized_variable) VariableType(existing_value);
|
|
||||||
// HOWEVER: C++ will intentionally not destroy the original copy, possibly leading
|
|
||||||
// to memory leaks of the original STL types. Not bad, not great. We're trading off safety
|
|
||||||
// for guaranteed memory leaks--initializing these variables with a default constructor is probably
|
|
||||||
// MUCH better in the long run.
|
|
||||||
//
|
|
||||||
// Ultimately, this comes down to the SDK ensuring all types have accessible constructors.
|
|
||||||
// Which SHOULD be a thing, but there's a lot of SDKs and I'm lazy enough to let this wait
|
|
||||||
// until it starts causing problems. This is what the macros do, so it really should be fine.
|
|
||||||
|
|
||||||
ResultType original_ret;
|
ResultType original_ret;
|
||||||
ResultType override_ret;
|
ResultType override_ret;
|
||||||
ResultType current_ret;
|
ResultType current_ret;
|
||||||
|
|||||||
@ -854,24 +854,6 @@ namespace SourceHook
|
|||||||
META_RES prev_res;
|
META_RES prev_res;
|
||||||
META_RES cur_res;
|
META_RES cur_res;
|
||||||
|
|
||||||
// TODO: STL operator= invocations beyond here can invoke corrupt destructors.
|
|
||||||
// this can lead to memory corruption/uninitialized memory use,
|
|
||||||
// as the STL operator= will try to call the destructor on the uninitialized
|
|
||||||
// member. If we see any memory corruption during operator= or similar,
|
|
||||||
// then that means we need to fix this and actually initialize these variables.
|
|
||||||
//
|
|
||||||
// One idea is to use placement copy constructors here, where we tell C++
|
|
||||||
// to initialize these variables with a copy constructor from another type:
|
|
||||||
// new (&uninitialized_variable) VariableType(existing_value);
|
|
||||||
// HOWEVER: C++ will intentionally not destroy the original copy, possibly leading
|
|
||||||
// to memory leaks of the original STL types. Not bad, not great. We're trading off safety
|
|
||||||
// for guaranteed memory leaks--initializing these variables with a default constructor is probably
|
|
||||||
// MUCH better in the long run.
|
|
||||||
//
|
|
||||||
// Ultimately, this comes down to the SDK ensuring all types have accessible constructors.
|
|
||||||
// Which SHOULD be a thing, but there's a lot of SDKs and I'm lazy enough to let this wait
|
|
||||||
// until it starts causing problems. This is what the macros do, so it really should be fine.
|
|
||||||
|
|
||||||
ResultType original_ret;
|
ResultType original_ret;
|
||||||
ResultType override_ret;
|
ResultType override_ret;
|
||||||
ResultType current_ret;
|
ResultType current_ret;
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user