-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-10-13 15:25, schrieb Jonathan Vollebregt:
The function takes a full key path so we can't just flat compare it to the root key strings - this way it stops checking for differences after the root key name.
Right, I didn't keep that in mind. Still there's the question of what should happen if the user passes a key path like HKEY_LOCAL_MACHINE_IBREAKYOU\Software\Wine .
Assuming you expect errors using RegCloseKey on a predefined key like HCKU: In practice it works just fine. I imagine it's supposed to work this way since testbot doesn't throw any errors either.
According to the RegCloseKey implementation in dlls/advapi32/registry.c you are correct. I can't find any tests for this behavior though. A comment may be in order if you intentionally relying on this behavior.
I've replaced that commit with a simpler one using a function to sanitize the path and leaving the flow control as it is in master:
https://github.com/jnvsor/wine/commit/25acdd930847d86022193ce4cc9cb83be32880...
This
patch is easier to read, but I am still wondering what the
- if (key[0] == '\') + key++;
and
- i = strlenW(key) - 1; + while (i >= 0 && key[i] == '\') +
key[i--] = 0;
parts are for. What do leading backslashes in a key do if they don't specify a remote host? Can there really be any number of trailing backslashes? What about trailing spaces like " \remote_host\HKLM\foo\bar"?
I've also fixed the duplicate call to path_get_rootkey_name in path_get_rootkey, changed the seperator>separator variable spelling, and added more detailed commit messages.
What else was there to deal with before re-submitting or is the WCHAR* in array of structs issue all that's left? (Oh for a char* to WCHAR* macro!)
There are plenty of things that need additional tests.