On Mon, Apr 6, 2020 at 4:38 PM davinder singh <davindersingh2...@gmail.com> wrote: > > Hi All, > > I am working on “pg_locale compilation error with Visual Studio 2017”, > Related threads[1],[2]. > We are getting compilation error in static char *IsoLocaleName(const char > *winlocname) function in pg_locale.c file. This function is trying to convert > the locale name into the Unix style. For example, it will change the locale > name "en-US" into "en_US". > It is creating a locale using _locale_t _create_locale( int category, const > char *locale) and then trying to access the name of that locale by pointing > to internal elements of the structure loct->locinfo->locale_name[LC_CTYPE] > but it has been missing from the _locale_t since VS2015 which is causing the > compilation error. I found a few useful APIs that can be used here. > > ResolveLocaleName and GetLocaleInfoEx both can take locale in the following > format. > <language>-<REGION> > <language>-<Script>-<REGION> > > ResolveLocaleName will try to find the closest matching locale name to the > input locale name even if the input locale name is invalid given that the > <language> is correct. > > en-something-YZ => en-US > ex-US => error > Aa-aaaa-aa => aa-ET represents (Afar,Ethiopia) > Aa-aaa-aa => aa-ET > > Refer [4] for more details > > But in the case of GetLocaleInfoEx, it will only check the format of the > input locale, as mentioned before, if correct it will return the name of the > locale otherwise it will return an error. > For example. > > en-something-YZ => error > ex-US => ex-US > aa-aaaa-aa => aa-Aaaa-AA > aa-aaa-aa => error. > > Refer [5] for more details. > > Currently, it is using _create_locale it behaves similarly to GetLocaleInfoEx > i.e. it also only checks the format only difference is for a bigger set. > I thought of using GetLocaleInfoEx for the fix because it behaves similarly > to the already existing and a similar issue was resolved earlier using the > same. >
It seems the right direction to use GetLocaleInfoEx as we have already used it to handle a similar problem (lc_codepage is missing in _locale_t in higher versions of MSVC (cf commit 0fb54de9aa)) in chklocale.c. However, I see that we have added a manual parsing there if GetLocaleInfoEx doesn't parse it. I think that addresses your concern for _create_locale handling bigger sets. Don't we need something equivalent here for the cases which GetLocaleInfoEx doesn't support? How have you ensured the testing of this code? I see that we have src\test\locale in our test directory. Can we test using that? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
