-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-11-04 21:15, schrieb Jonathan Vollebregt:
+#define ERROR_NAN 20002
ERROR_NEGATIVE_VALUE would be a better name since NAN is a floating point thing.
+static LSTATUS data_default(const DWORD type, DWORD *size_out, BYTE **out)
I think the old behavior of passing NULL to RegSetValueExW if no data is specified with /d was nicer. That's assuming it does the right thing for all data types. This may need tests in advapi32/tests/registry.c
The bottom line of this suggestion and things like passing a NULL HKEY to RegOpenKey in patch 3, or trailing backslashes in patch 2 is to leave as much error handling to the advapi32 functions as possible. I think reg.exe should be a fairly minimal string parsing program that blindly forwards everything to advapi32 and doesn't do much checking on its own. The exception are kinda of errors that are not possible in advapi32 by design, like a negative REG_DWORD. You're welcome to prove me wrong with tests that show advapi32 and reg.exe error handling differ :-)
Another possibility is that native assumes a default value string of "" if /d is not specified, which then produces behavior like an empty REG_SZ and fails to convert into a DWORD.
{
- LPBYTE out_data = NULL;
- *reg_count = 0;
- switch (type)
- {
...
case REG_DWORD:case REG_DWORD_BIG_ENDIAN:{return ERROR_NAN;}
It's odd that there isn't a default value for REG_DWORD, 0 would be a logical choice. But the tests confirm this... But I don't see why you haven't removed the todo_wine from the according test.
default:return ERROR_UNSUPPORTED_TYPE;
I think this is a bad place to catch unsupported data types. "type" comes from one of your own functions, namely wchar_get_type(). If reg.exe shouldn't support any of the data types not explicitly handled here then wchar_get_type should already return an error in this case. Otherwise you can make this a FIXME("Add support for type %u\n" type);
-
Stefan Dösinger