[PATCH v4 5/8] reg.exe: Add wchar/raw data conversion functions

[Jonathan Vollebregt]

Clearing some stuff up here

On 10/12/2014 05:03 PM, Stefan Dösinger wrote:
> From a design point of view it unfortunate that you allocate a new string for the REG_SZ and REG_SZ_MULTI case and essentially just do a memcpy and free the old string.

I don't free the old string. Because the function handles more than one 
type of data the caller has to free the data when it's done - if I don't 
copy the string it will end up freeing one of it's own parameters.

Now that I think of it I'm not sure what will happen then, but 
presumably you'll get a segfault since parameters should be on the stack.

> If I understand this correctly this replaces 0 WCHARs with ',' . There should be nicer ways to do this.

Sorry, this seems confusing without comments. The REG_MULTI_SZ stores 
multiple strings in the registry: nil separated with a double nil to end 
the array.

When reading from the registry simply replacing the nil's with ',' seems 
the simplest way to do it, and that's exactly wine's regedit's 
behaviour. I'm not sure what the native behaviour is supposed to be though.

> How does a 0 separator work? The command line interpreter would fail to parse such a string. msdn claims that the default separator is '\0', but maybe they mean a backslash ('\\') like your code uses. If the default separator is a backslash it would be nicer to handle this default in the code that parses the command line.

If the separator has been left out of the commandline, the separator 
variable here will be 0. By default reg (From everything I've read) 
interprets "\\0" as the separator - that is it takes an escaped nil as 
it's input to split the strings.

If you *do* supply a separator variable though it will split by that, so 
the following commands should have an equivalent effect:

reg add HKCU /v test /t REG_MULTI_SZ /d "string\\0morestring"
reg add HKCU /v test /t REG_MULTI_SZ /s "#" /d "string#morestring"