FIX Re: Apparent Stack Corruption with std.windows.registry

[Jay Jacobson]

I was tinkering with this some more this morning and located and fixed
two bugs in std.windows.registry.

The first was on line 691 and had to do with setting the cbData value to be the size of a DWORD 8. This lead to the odd problem pointed at in the previous post. This caused all string registry values with a size less than 8 to become corrupted because the fall-through test of "too small a buffer" was skipped. In the case of a string, you can't know what the size is in advance without first calling the function to obtain the correct size to allocate. The subsequent call then works (the fall-through test).

Unfortunately, the one liner fix caused the DWORD registry entries to not be read correctly which lead to the addition of the case statement to appropriately set the "data" variable ptr (might be a better way to do this).

Additionally, I found that the EXPAND_SZ method was not stripping a trailing NULL from the ExpandEnvironmentStringsA call. 

With the attached changes, the std.windows.registry module passes the "works for me" test... without needing any of the "strip nulls" logic as in the wiki example... YMMV

By the way, Scite made seeing these errors really easy in the output file.

Thanks,
Jay

Jay Jacobson Wrote:

> I've been working with the example from this location:
> http://www.dsource.org/projects/tutorials/wiki/RegistryEnumerationExample
> 
> It is obvious from that example that there is some kind of issue with the module. However, I've put a simple test app together based on that code which appears to show some form of what looks like stack corruption going on around that module. I was able to generate an uncorrupted file by going within the module (std.windows.registry) for the output.
> 
> There are three files created by the test app (dumpuninstall.d):
> Installed.txt - which is corrupt
> Installed2.txt - which is not corrupt
> Installed3.txt - which is corrupt, but which is basically on the receiving end of a trivial return from where Installed2.txt is created within the module.
> 
> You can comment and uncomment some trivial code and change what the corruption looks like (within the modified registry2.d file).
> 
> The same registry values always appear to be corrupted. I haven't seen a definite reason for why that is. Perhaps it has something to do with the number of characters ran through the interface or possibly some DWORD reads (though that isn't consistent in all cases).
> 
> I've gotten what I need with the uncorrupted Installed2.txt. I am posting this here so that perhaps, the use of the interface as it is intended might be enabled by someone with more D experience. 
> 
> I've only been working with D for a few days, but I'm really liking it.
> Thanks for the effort,
> Jay
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: src.zip
Type: application/zip
Size: 12370 bytes
Desc: not available
Url : http://lists.puremagic.com/pipermail/digitalmars-d-bugs/attachments/20070114/c34ddc41/attachment.zip