[2/5] dinput: SetActionMap saving simple configurations to an .ini file (try 2)

Vitaliy Margolen wine-devel at kievinfo.com
Tue Jan 10 19:53:46 CST 2012


On 01/10/2012 10:51 AM, Lucas Zawacki wrote:
> 2012/1/10 Vitaliy Margolen<wine-devel at kievinfo.com>:
>> On 01/09/2012 10:18 AM, Lucas Fialho Zawacki wrote:
>>>
>>> From: Lucas Fialho Zawacki<lfzawacki at gmail.com>
>>>
>>> +static BOOL _write_private_profile_intW(const char *format, WCHAR*
>>> section, WCHAR* key, int value, WCHAR* file)
>>
>> I don't think this is such a good idea to mix ASCII and WCHAR parameters.
> Even if this is for convenience in my "private" code? I use this a
> great deal through the code.
Always converting static text from ASCII to Unicode during run-time is not a 
good thing. Yes it sucks that we have to define all Unicode strings as 
arrays. But such as life.

>> Why do you think it should be there in the first place?
> Windows keeps it there, you can check it by running any application
> using SetActionMap. But I suppose no application depends on it being
> there specifically.
Just because Windows does something is not good enough of an excuse to do 
the same. AJ said that on many occasions... Here it seems really suspicious 
that any user can create files inside a program install directory structure. 
And those files not even executables or libraries... If anything these files 
belongs under user's profile local data files directory.

> Yes, you're right. There were other mistakes as well. Is this version better?
>
>      ...
>      while (1)
>      {
>          /* Test if it's the first time */
>          if (buffer == NULL)
>              buffer = HeapAlloc(GetProcessHeap(), 0, size*sizeof(WCHAR));
>          else
>              buffer = HeapReAlloc(GetProcessHeap(), 0, buffer,
> size*sizeof(WCHAR));
Nope, you clobber original value of "buffer" and what you had before is 
lost. So in case it fails you leaking old buffer.

However I really don't like this function, and how it's used. If all you 
need is to format some strings, then you should provide your own buffer for 
such a function and let it grow it if needed to. Then you save time by not 
allocating / freeing same buffer multiple times.

>> Would you please drop leading underscore from all of your function names?
> Ok. I can stop doing this from this patch onwards if you think this
> convention is bad.
In *NIX world only system functions deserve leading underscore...

- Vitaliy



More information about the wine-devel mailing list