diff options
author | Yang Tse <yangsita@gmail.com> | 2013-07-18 20:04:02 +0200 |
---|---|---|
committer | Yang Tse <yangsita@gmail.com> | 2013-07-18 23:37:33 +0200 |
commit | 90695fb2c508803a09581b0ca8f55eaa36749a69 (patch) | |
tree | 8ba98611465b9639fada7c24aef8e420f46405b2 /tests/certs/Server-localhost-sv.pem | |
parent | dd17069c9e307ff135f4eb572671bd351f7e6a42 (diff) |
Reinstate "WIN32 MemoryTracking: track wcsdup() _wcsdup() and _tcsdup() usage".
This reverts commit 7ed25cc, reinstating commit 8ec2cb5.
As of 18-jul-2013 we still do have code in libcurl that makes use of these
memory functions. Commit 8ec2cb5 comment still applies and is yet valid.
These memory functions are solely used in Windows builds, so all related
code is protected with '#ifdef WIN32' preprocessor conditional compilation
directives.
Specifically, wcsdup() _wcsdup() are used when building a Windows target with
UNICODE and USE_WINDOWS_SSPI preprocessor symbols defined. This is the case
when building a Windows UNICODE target with Windows native SSL/TLS support
enabled.
Realizing that wcsdup() _wcsdup() are used is a bit tricky given that usage
of these is hidden behind _tcsdup() which is MS way of dealing with code
that must tolerate UNICODE and non-UNICODE compilation. Additionally, MS
header files and those compatible from other compilers use this preprocessor
conditional compilation directive in order to select at compilation time
whether 'wide' or 'ansi' MS API functions are used.
Without this code, Windows build targets with Windows native SSL/TLS support
enabled and MemoryTracking support enabled misbehave in tracking memory usage,
regardless of being a UNICODE enabled build or not.
Diffstat (limited to 'tests/certs/Server-localhost-sv.pem')
0 files changed, 0 insertions, 0 deletions