Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
I must be missing something, but I thought regular strings can not contain embedded nulls, so we can have a simple rule: don't store terminating nulls for simple strings, but store them for multi-strings.
<me-thinks> Aha -- you mean that if we follow this rule, all is good, but we will not be backwards compatible because currently multi-strings don't have the embedded nulls, right?
Right; though the problem happens for regular strings too, they don't necessarily have to be null terminated. And of course it would require everybody editing the file to always remember to add terminating nulls, which is much less user-friendly than what we have now.
In that case, I guess we already have a versioning mechanism for the registry files, so we'll just have to go to the next version, and convert the old files to the new format.
That's a major PITA, certainly not justified for such a minor problem that hasn't been demonstrated to cause any trouble in practice.
What does PITA stand for?
I assumed bug 824 was on the "tasklets" list because it was a requirement for Wine 0.9 and/or 1.0. Going back to the original comments the complaint was Wine's instance on storing the last \0 regardless. Hence certain REG_MULTI_SZ values can not be reliably stored and retrieved...
hex(7): <-- length = 0 hex(7):01 <-- length = 1
They come out as:
hex(7):00 hex(7):01,00
Of course inside user.reg Wine has stored...
=str(7):"" =str(7):"\1"
The only way I can see of satisfying the requirements for readability & editability would be to explicitly store the length of multi-strings thusly...
=str(7),len=0:"" =str(7),len=1:"\1"
Yet still allow for an implied length when one was not supplied, such as....
=str(7):"one\0two\0three\0"
Of course this raises the question of what to do when length and data conflict...
=str(7),len=20:"small\0"
Alas, no easy answers it would seem :(
Kind regards, -Randy Galbraith