#1260 Pass variable pointer to allow reallocation

[Miguel Barro Otero]

This plugin generates issues when working with registry entries larger than the initial allocation size of 10*1024 kB.
We have introduced a bugfix that may be useful:
https://github.com/GsNSIS/EnVar/pull/4

[Jason]

The initial allocation is actually nsis strlen + 4; which is (1024 * 1) + 4 for ansi, and (1024 * 2) + 4 for unicode. Anyway, ReadRegVar() should automatically realloc the space it needs for the registry value.

If you can give an example script that fails, then I can look into it (also it looks like you are using a slightly older version of the plugin, try the wiki version first and see if that works).

[Jason]

Just to clarify, 1024 is the string size for standard nsis, the long string version is 8192. It is not hardcoded to 1024 in the code.

[Miguel Barro Otero]

Sorry, I gave a poor explanation and misguided you. I'll try to clarify.

• NSIS variables have a size (1024+4) usually (but is build dependent) as you have remarked.
• Windows Registry entries are able to manage over 1 Mb (though larger values use is discouraged).
  The NSIS native APIs that handle registry values use a NSIS variable as buffer, thus there were problems that led to the introduction of the EnVar plugin. This plugin introduces APIs that use NSIS variables only to append or remove values to registry entries. This way NSIS can handle registry entries well over the NSIS variable size (only the additions or removals size is constrained).
  The issue we detected was that the EnVar plugin internal buffer (which is by default 10xNSIS variable size) was wrongly reallocated. If reallocation took place the buffer global pointer was not updated and keep pointing the old memory location. This led to undefined behavior on the generated installer (either it hanged or crashed).
  We only wanted to hint that there was a path available on github.
  The github repo has a specific test that reproduces the issue:
  https://raw.githubusercontent.com/GsNSIS/EnVar/master/Tests/PluginTest.nsi
  Hope I make myself clear 😀

[Jason]

Oh I see. I'll rewrite the failing test in C so I can debug it properly (using a .exe instead of a dll).

[Jason]

So I ended up rewriting most of the plugin to use a double linked list, I wanted to write a better parser for it anyway so why not. I have also added two more error codes, which means the error code order has changed.

On a side note, I took your test script and tested the upper limit with 320000, it took a couple of minutes to process but it returned a success code. Removing those paths was the same, took a couple minutes but returned a success code.

New version is on the wiki now :) .