Re: VS 2015 support in src/tools/msvc - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: VS 2015 support in src/tools/msvc
Date
Msg-id 570A6A14.6040303@dunslane.net
Whole thread Raw
In response to Re: VS 2015 support in src/tools/msvc  (Christian Ullrich <chris@chrullrich.net>)
Responses Re: VS 2015 support in src/tools/msvc  (Christian Ullrich <chris@chrullrich.net>)
List 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.paquier@gmail.com> wrote:
>>> On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich <chris@chrullrich.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




pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Parallel Aggregate costs don't consider combine/serial/deserial funcs
Next
From: Alvaro Herrera
Date:
Subject: Re: pgbench - allow backslash-continuations in custom scripts