-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-10-28 12:21, schrieb Jonathan Vollebregt:
Inconsistent curly bracket placement. The other patches have more cases of that.
Should the arrays also have the opening brace on it's own line? A quick grep shows both styles for arrays in wine.
The one line arrays (e.g. short_hklm) no, the two-line or longer ones yes.
The tests show that having any backslash at the start results in an error. That particular if just picks which error message to show.
Yes, but you could just check for two backslashes and proceed normally otherwise. You'll then write the same error message because you cannot find "\HKEY_CURRENT_USER" in your root key table.
reg/tests/reg.c:109 shows only the winXP version accepts multiple trailing backslashes.
The reason for stripping a single trailing backslash was for output consistency with query (As yet unimplemented) Specifically whether query outputs "HKEY_CURRENT_USER\key" or "HKEY_CURRENT_USER\key\" as the key name.
It'd be better to add this functionality together with query support then. Maybe keep it inside query only.
Is there a advapi32 function go get a string name for an open HKEY handle? You could use that to normalize printed paths. That could also take care of e.g. upper and lower case letters.
Because the input is the full path we have to stop comparing after the root key or it will always return 0 unless it's passed a root key.
I think the "path" parameter name makes this more obvious, but I could throw a comment in if that helps.
Nah, it should be possible to make this function readable without a comment. How about the names "input_path" and "root_key_name"?
Actually this solves 2 separate problems. RegOpenKey takes the path after the root key but the path provided includes the root key, so strchrW skips the root key in the path in advance of passing it to RegOpenKey.
Yes, you need the strchrW call.
On the other hand, if someone inputs only a root key IE "HKCU" it will return NULL. We already have the key from path_get_rootkey, so we just return it here.
I don't think you need the NULL check with the early return, and I don't think you need to strip the trailing \ in sanitize_path. Removing those (not accounting for reg query for now) will remove two code branches that need testing and make the code more difficult to read.
That's assuming RegOpenKey behaves as intended in those cases:
Msdn says RegOpenKey(key_in, NULL, &key) returns key == key_in, so no need for the early return in the case that strchrW returns NULL. If the behavior is the same in RegOpenKey(key_in, "\", &key) there's no need to strip trailing backslashes.
Maybe RegOpenKey(NULL, xxx, &key) returns an error that you can propagate to main() and translate into an error message there. In that case you don't have to write an error message from a helper function.
The RegOpenKey behavior may need additional tests in advapi32.