You did not read my ticket correctly or do not understand it.
when compiling with the Debug CRT, it *does not zero the memory*, it sets it to different debug values depending on the type/method of allocation (see the link I provided (http://stackoverflow.com/questions/370195/when-and-why-will-an-os-initialise-memory-to-0xcd-0xdd-etc-on-malloc-free-new). Additionally, it will fill buffers for different string and memory copy/allocation functions for debug purposes.
This means you *cannot run extensions compiled against the Debug CRT*, only built against the release CRT. It's not world ending, but its annoying when working on complex extensions. That means, if you do something to the affect of:
ACE_VD_EXPORT void __stdcall RVExtension(char *output, int outputSize, const char *function) {
sprintf_s(output, outputSize, "My Balls");
}
The debug CRT writes:
output = My Balls 0x00 0xFE 0xFE 0xFE 0xFE
Thus triggering this warning. Which has nothing to do with a buffer overflow, its just that the 2nd to last byte they provided me is not null.
This can be worked around in the extension by setting the 2nd-to-last output byte to 0x00 no matter what.
Ideally though, this should be appropriately handled with a correct guard byte after the buffer - not a guard byte inside the buffer sent to the function.
This does not occur in release builds because ArmA3 zero'es the buffer prior to passing it to you; its specifically your extensions debug flag which is re-writing the buffer.