From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, davinder singh <davindersingh2692(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG compilation error with Visual Studio 2015/2017/2019 |
Date: | 2020-04-19 11:56:39 |
Message-ID: | CAEudQAoFcXDSeZgk1EML-qMVVyTN4=tgqd-GNi3Vtz0bO=XJnA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg토토 꽁 머니SQL |
Em dom., 19 de abr. de 2020 às 07:16, Juan José Santamaría Flecha <
juanjo(dot)santamaria(at)gmail(dot)com> escreveu:
>
> On Sat, Apr 18, 2020 at 6:07 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
>
>> On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha
>> <juanjo(dot)santamaria(at)gmail(dot)com> wrote:
>> >
>> > We can get a match for those locales in non-ISO format by enumerating
>> available locales with EnumSystemLocalesEx(), and trying to find a match.
>>
>> I have not reviewed or tested the new patch but one thing I would like
>> to see is the impact of setting LC_MESAGGES with different locale
>> information. Basically, the error messages after setting the locale
>> with _create_locale and with the new method being discussed. This
>> will help us in ensuring that we didn't break anything which was
>> working with prior versions of MSVC. Can you or someone try to test
>> and share the results of the same?
>>
>
> I cannot find a single place where all supported locales are listed, but I
> have created a small test program (WindowsNLSLocales.c) based on:
> <language>[_<location>] format locales [1], additional supported language
> strings [2], and additional supported country and region strings [3]. Based
> on the results from this test program, it is possible to to do a good job
> with the <language>[_<location>] types using the proposed logic, but the
> two later cases are Windows specific, and there is no way arround a
> lookup-table.
>
> The attached results (WindowsNLSLocales.ods) come from Windows 10 (1903)
> and Visual C++ build 1924, 64-bit.
>
> On Sat, Apr 18, 2020 at 1:43 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
>
>> I have some observations about this patch, related to style, if you will
>> allow me.
>>
>
> Please find attached a revised version.
>
Looks good to me, but, sorry, I think I missed a glitch in the previous
review..
+#else /* _WIN32_WINNT < 0x0600 */
+ _locale_t loct;
+
+ loct = _create_locale(LC_CTYPE, winlocname);
+ if (loct != NULL)
+{
+ rc = wchar2char(iso_lc_messages, loct->locinfo->locale_name[LC_CTYPE],
+ sizeof(iso_lc_messages), NULL);
_free_locale(loct);
+}
+#endif /* _WIN32_WINNT >= 0x0600 */
If _create_locale fail, no need to call _free_locale(loct);.
Another point is, what is the difference between pg_mbstrlen and wcslen?
It would not be better to use only wcslen?
Attached have the patch with this comments.
regards,
Ranier Vilela
Attachment | Content-Type | Size |
---|---|---|
0001-PG-compilation-error-with-VS-2015-2017-2019_v08.patch | application/octet-stream | 5.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-04-19 12:50:27 | HEAPDEBUGALL is broken |
Previous Message | Dmitry Dolgov | 2020-04-19 11:48:20 | Re: WIP: WAL prefetch (another approach) |