alex wrote:This way of communicating won't take you far.
If you know wchar_t is 32 bit, why are you trying to deal with as if it was 16 bit and why are you surprised when it does not do what you intend?
If you think this is a bug, why don't you file a bug report?
Because I wanted to be sure that it really is a bug. Thus my original post: "Is this a bug?"
alex wrote:Documentation (and parameter names) clearly states that this is a 16-bit value.
Actally it doesn't! Using "wchar_t" determines the size of a single data element, not the type of data you choose to store in it. You could well store UTF32 using multiple "char"s.
There simply is no standard character type which is 16bits wide, so you'll have to use the 32bit wchar_t. Putting shorter info in longer datatypes must work - otherwise it would also be a problem to assign a "char" to an "int" variable.
alex wrote:This is not a bug any more than non-standardized wchar_t size is a bug. Right or wrong, this is currently a feature.
Well, I do expect the function to work as described in the documentation - which it does not.
alex wrote:You can try to fix it by submitting a patch in SourceForge. I will personally look into it and do the best to make it more robust.
I'll look into it.