Re: Janitorial dlls/advapi32/registry.c W->A cleanup

[Tony Lambregts]

Tony Lambregts wrote:

Dmitry Timoshkov wrote:

"Tony Lambregts" <[EMAIL PROTECTED]> wrote:

 

-LONG WINAPI RegSaveKeyW( HKEY hkey, LPCWSTR file, 
LPSECURITY_ATTRIBUTES sa )
+LONG WINAPI RegSaveKeyA( HKEY hkey, LPCSTR file, 
LPSECURITY_ATTRIBUTES sa )
{
-    LPSTR fileA = HEAP_strdupWtoA( GetProcessHeap(), 0, file );
-    DWORD ret = RegSaveKeyA( hkey, fileA, sa );
-    if (fileA) HeapFree( GetProcessHeap(), 0, fileA );
+    UNICODE_STRING fileW;
+    LONG ret;
+
+    RtlCreateUnicodeStringFromAsciiz( &fileW, file );
+    ret = RegSaveKeyW( hkey, fileW.Buffer, sa );
+    RtlFreeUnicodeString( &fileW );
    return ret;
  


In the vast majority of cases where an API takes file name, ANSI version
of the API is supposed to have a limitation of MAX_PATH characters for
the name.
Thus, there is no need to waste CPU cycles by allocating/deallocating
memory, but instead having an automatic buffer on the stack will be
quite enough. See files/drive.c,GetCurrentDirectoryA for a sample.
All other APIs which get a file name as a parameter should be rewritten
that way too. Probably that's the task for yet another janitorial 
project...

All the said above doesn't mean that your patch can't applied as is,
that just means that there is a better way of doing this task.
 

Yeah I actually had it that way at one point due to my familairity 
with drive.c and well... I ran into some compiler errors (in 
RegSaveKeyW) that ended up making the problem worse. Perhaps it was 
something I simple I missed. I can take another look at it if it will 
save some CPU cycles.
when I change the code to the following
LONG WINAPI RegSaveKeyA( HKEY hkey, LPCSTR file, LPSECURITY_ATTRIBUTES sa )
{
   WCHAR fileW[MAX_PATH];
   LONG  ret, len;
  
   len = WideCharToMultiByte(CP_ACP, 0, fileW, -1, file, 0, NULL, NULL);
   WideCharToMultiByte(CP_ACP, 0, fileW, -1, file, len, NULL, NULL);
   ret = RegSaveKeyW( hkey, fileW.Buffer, sa );
   return ret;
}

I get the following warning

warning: passing arg 5 of `WideCharToMultiByte' discards qualifiers from 
pointer target type

WideCharToMultiByte does not like LPCSTR. So what to do?

--

Tony Lambregts