Re: More Norwegian trouble

On Thu, Jan 08, 2015 at 04:37:37PM +0200, Heikki Linnakangas wrote:
> setlocale(LC_COLLATE, NULL) -> "Norwegian (Bokmål)_Norway"
> 
> but:
> 
> setlocale(LC_COLLATE, "norwegian-bokmal_Norway") -> "Norwegian_Norway")

> Apparently the behavior changed when I upgraded the toolchain. IIRC, I used
> to use "Microsoft Windows SDK 7.1", with "Microsoft Visual C++ Compilers
> 2010 Standard Edition" that came with it. I'm now using "Microsoft Visual
> Studio Community Edition 2013 Update 4", with "Microsoft Visual C++
> Compilers 2010 SP Standard". I don't know what part of the upgrade broke
> this. Could also have been something else; I don't keep track of my build
> environment that carefully.

MSVCR110 (Visual Studio 2012) locale handling departed significantly from that
of its predecessors; see comments at IsoLocaleName().

> Now, what should we do about this? I'd like to know if others are seeing
> this, with whatever compiler versions you are using.

VS2012 x64 behaves roughly as you describe:

setlocale(LC_COLLATE, NULL)                        -> "Norwegian (Bokmål)_Norway"
setlocale(LC_COLLATE, "norwegian-bokmal_Norway")   -> "Norwegian_Norway.1252"
setlocale(LC_COLLATE, "Norwegian_Norway")          -> "Norwegian_Norway.1252"
setlocale(LC_COLLATE, "Norwegian (Bokmål)_Norway") -> "Norwegian (Bokmål)_Norway"

I see the traditional behavior with 64-bit MinGW-w64 (MSVCRT):

setlocale(LC_COLLATE, NULL)                      -> "Norwegian (Bokmål)_Norway"
setlocale(LC_COLLATE, "norwegian-bokmal_Norway") -> "Norwegian (Bokmål)_Norway"
setlocale(LC_COLLATE, "Norwegian_Norway")        -> "Norwegian (Bokmål)_Norway"

> In particular, I wonder
> if the builds included in the EnterpriseDB installers are experiencing this.

I strongly suspect those builds use VS2012 for some of the newer branches, so
they will be affected.

> Perhaps the nicest fix would be to change the mapping code to map the
> problematic locale name to "Norwegian_Norway" instead of "norwegian-bokmal".
> That's assuming that it is in fact the same locale, and that it's accepted
> on all supported Windows versions.

I bet it is always accepted and always refers to the same locale.  IIRC,
interpretation of these names falls entirely within the CRT.  Windows system
libraries have no concept of these naming schemes.

> It would be good to do something about this before the next minor release,
> as the original mapping commit has not been released yet.

+1