On 07/01/2016 08:25 AM, Daniel Pfeifer wrote: > On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns <davis...@gmail.com> wrote: >> On Windows getenv uses ANSI codepage so it needs to be encoded to >> internally used encoding (eg. UTF-8). Here we use _wgetenv instead >> and encode that.
Thanks. Clinton (in Cc) did quite a bit of work to get argv[] and file processing to use wide character APIs on Windows. It looks like environment variables are next. > Your change to the SystemTools::GetEnv function introduces memory > leaks, since you return a pointer to a new[]-ed array. > It seems impossible to refactor SystemTools::GetEnv to use _wgetenv > and provide interface compatability. We could keep our own std::map around to own the memory and use that to retain compatibility in the existing API. It would be nice to also offer an alternative API that passes ownership of the result to the caller. > You should probably introduce a function that returns std::string and > uses GetEnvironmentVariableW internally. The signature also needs to allow callers to determine whether the environment variable was set to empty or not set at all. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
