[PATCH 5/7] reg: Add wchar/raw data conversion functions

[Stefan Dösinger]

-----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);

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJUWVSuAAoJEN0/YqbEcdMwd9IP/A2J8L9/QJxCHc+g+rOFI/GB
y+NA9dQJ2MXnCC7DeGU0myblOeRlTkFRqA3R/isM21IBSmOPLseLqSexzuvf8fwf
y1cSEZ49z3yLI7rrVt0VEhX8p9dqkczU+W3GWE2M9jOkP88pxNSPsm5vIO+VtJRi
1GqGp3Snz4NQ6jCQGHn30M4vwgxRXS0gxkmGj1iEcA772vEWpNuAOptDQ9j0fGan
aXzdmQMF8VDJMeGR6uI+8JuM2ERAjt9EE/2PGLjH0b9zpPR8V7Z+ECqPJh9kTJv6
wxM1wCHzsGXDQYlqQzQjaoWNIchrEybqgnaar0KS4H0+Hz8DKOz1StDB5bfQ2bHi
lBiQ5a4T6AXOlNOH49RiLcPLrHUoUcmvFd+Cr4HngySeu0WkFvtsfdFjppJW+nrw
aXMuKoZpje0+5EjTgI255Oi6vZnx+piy1hRn1zSTE5xq9lnyEPVaemtus77x4rOL
82/TChrSaeYg/uXrFNWFZG9fb38L2EIyeIQSLZwTYIHrE6p2IGp1AnMPkDcM4TcC
rMQXEW3IPdmR2EXf2gZ0PuU3Sab4M9dWuMsJ/E4H6vOu/d9/BfnGle1TR6hP6Pqu
XlZrjrm0Ifh/fnWec75Yc6rpj1Ueen4C1/dAxjDe3sn509qAvfREUtUH3psBLGXQ
uCkQoWInlbV4UmVjl1Gg
=hZLk
-----END PGP SIGNATURE-----