From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Christian Ullrich <chris(at)chrullrich(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: VS 2015 support in src/tools/msvc |
Date: | 2016-04-10 14:58:28 |
Message-ID: | 570A6A14.6040303@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/09/2016 08:43 AM, Christian Ullrich wrote:
>> Michael Paquier wrote:
>>
>> On Sat, Apr 9, 2016 at 7:41 AM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>>> On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich <chris(at)chrullrich(dot)net> wrote:
>>>> * Andrew Dunstan wrote:
>>>>>> On 04/08/2016 11:02 AM, Christian Ullrich wrote:
>>>>>> src/port/chklocale.c(233): warning C4133: 'function': incompatible
>>>>>> types - from 'const char *' to 'LPCWSTR' [...\postgres.vcxproj]
>>>>> Do you have a fix for the LPCWSTR parameter issue?
>>>> As long as the locale short name cannot contain characters outside of ASCII,
>>>> and I don't see how it could, just the typical measure-allocate-convert
>>>> dance, add error handling to taste:
>>>>
>>>> int res = MultiByteToWideChar(CP_ACP, 0, ctype, -1, NULL, 0);
>>>> WCHAR *wctype = malloc(res * sizeof(WCHAR));
>>>> memset(wctype, 0, res * sizeof(WCHAR));
>>>> res = MultiByteToWideChar(CP_ACP, 0, ctype, -1, wctype, wctypelen);
>> I don't think that's good to use malloc in those code paths, and I
>> think that we cannot use palloc as well for a buffer passed directly
>> into this function, so it looks that we had better use a fix-sized
>> buffer and allocate the output into that. What would be a a correct
>> estimation of the maximum size we should allow? 80 (similar to
>> pg_locale.c)?
> I think it should not take more than 16 characters, but if you want to make sure the code can deal with long names as well, MSDN gives an upper limit of 85 for those somewhere.
>
I don't think we need to be too precious about saving a byte or two
here. Can one or other of you please prepare a replacement patch based
in this discussion?
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-04-10 15:06:42 | Re: pgsql: Add the "snapshot too old" feature |
Previous Message | David Rowley | 2016-04-10 12:47:29 | Parallel Aggregate costs don't consider combine/serial/deserial funcs |