On 07/21/2016 01:22 PM, Dāvis Mosāns wrote:
> +namespace @KWSYS_NAMESPACE@
> +{
> + class ProcessOutput
> + {
Let's just add this to CMake proper first. The one use case in
KWSys SystemInformation is not really necessary because it is
only in code paths used on non-Windows systems. We can always
move this to KWSys later.
> + bool DecodeText(std::string raw, std::string& decoded)
> + {
> + bool success = true;
> + decoded = raw;
> +#if defined(_WIN32)
> + if (raw.size() > 0 && codepage != defaultCodepage) {
> + success = false;
> + const int wlength = MultiByteToWideChar(codepage, 0, raw.c_str(),
> int(raw.size()), NULL, 0);
Why do we need new calls to MultiByteToWideChar instead of
having clients just directly use kwsysEncoding_mbstowcs?
This may become moot given the buffer boundary problems
discussed in another branch of this thread.
-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
