On Mon, Apr 6, 2020 at 4:38 PM davinder singh
<davindersingh2692@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.
Thisfunction 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
thename of that locale by pointing to internal elements of the structure loct->locinfo->locale_name[LC_CTYPE] but it
hasbeen missing from the _locale_t since VS2015 which is causing the compilation error. I found a few useful APIs that
canbe 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
nameis 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
correctit 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
onlydifference is for a bigger set.
> I thought of using GetLocaleInfoEx for the fix because it behaves similarly to the already existing and a similar
issuewas 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
