Unicode Windows

[philrosenberg]

When Unicode encoding is set on Windows there are some compiler warnings about casting TCHAR* to char*. Running udunits2 gives garbage, presumably because the encodings are all wrong.

[semmerson]

@philrosenberg I'm not a Windows expert. How does one set Unicode encoding on Windows? Do you have a simple sequence of steps to illustrate the problem?

[philrosenberg]

Hello StevenTo set Unicode you need to add /DUNICODE and /D_UNICODE to the CFLAGS (and CXXFLAGS) environmental variable(s) before running Cmake. I use the Visual Studio 11 generator. Alternatively after creating a visual studio project from CMake and opening it, you can right click the  libudunits2 and udunits2 projects and select properties, then go to Configuration properties -> General and for the Character Set property select Use Unicode Character Set. I have, however just found that the bug I found is not to do with Unicode at all. The bug was that when running UDUNITS with no command parameters I get garbage output followed by an actual error message because I have not set the environmental variables for the encoding. I thought the garbage output was because of UTF16 encoding. Actually it is because in the decodeCommandLine function _progname is set using _progname=tmp, where tmp is allocated on the stack. So when tmp goes out of scope _progname is left as a dangling pointer. Despite this, there are still some Unicode issues that probably should be dealt with. getopt uses TCHAR * for strings and under Unicode these resolve to wchart* rather than char. Despite this, char_ parameters are being passed in and cast as wchar_t* and then being variously cast back to char* when passed to other functions. Basically things need to be set to either use TCHARs and pass them to macro function wrappers which resolve to either ascii or UTF-16 forms depending upon the build type, or use only chars and use ascii functions. Also beware of api functions which accept TCHARs, e.g. it seems like _tsplitpath takes TCHAR strings, but it is always passed ASCII strings - or maybe it is passed wchart* UTF16 strings cast as char, then recast to wchart, because it seems to be working okay - you see the potential for confusion. Building with Unicode enabled on a Windows system should highlight most of these issues with warnings about casting between pointer types. I'm not sure that was very coherent. Sorry. If it is helpful I can try to go through some of the code and try to pick out problems and do a pull request. But I'm not sure when I will find time. Phil   From: Steven Emmerson notifications@github.com To: Unidata/UDUNITS-2 UDUNITS-2@noreply.github.com Cc: Phil Rosenberg philip_rosenberg@yahoo.com Sent: Tuesday, 30 September 2014, 16:32 Subject: Re: [UDUNITS-2] Unicode Windows (#24)

Phil, I'm not a Windows expert. How does one set Unicode encoding on Windows? Do you have a simple sequence of steps to illustrate the problem?— Reply to this email directly or view it on GitHub.