fix: Events.numEvents should be int32_t, not int64_t

[vsariola]

My VST instrument was crashing in FL Studio 21.0.3 (build 3517, win64). I pinned the reason to here:

vst2/include/vst.h

Line 84 in 08ee2a4

int64_t numEvents;

I got 4294967376 numEvents (!) which strongly suggested that numEvents was supposed to be 32-bit integer after all, not a 64-bit integer.

Back in my pull request, I changed the numEvents to int64_t because in an old VST plugin on the internet, it was defined as long (https://github.com/hzdgopher/4klang/blob/master/4klang_source/Go4kVSTi/source/common/aeffectx.h), which I assumed to be 8 bytes on 64-bit systems.

However, in some other places, (https://github.com/R-Tur/VST_SDK_2.4/blob/master/pluginterfaces/vst2.x/aeffectx.h), it's clearly int32_t. I changed it back to int32_t and it seems the crashes in FruityLoops are solved. I assume that the old vst2 header was always compiled in 32-bit, where long is 4 bytes, but when moving to 64-bit, they also updated the headers.

To be pedantic, the second "reserved" part is big enough for a pointer. On 64-bit, of course it does not matter if it is int64_t or void*, but in 32-bit, it changes the offset of the events.

How could numEvents accidentally defined as int64_t work at all? I assume it came down to two things: 1) if the host guarantees the unused part of the struct being 0s; and 2) the struct packing rules of C guarantee that the event pointers, having size of 8 bytes, are aligned to 8 bytes i.e. the events will be at offset +16 regardless of what.

It seems that older versions of FL and Renoise respected 1, but the newest not.

Oh, and I added a simple null guard, in case the host ever sends a null pointer in the events array. I don't know if hosts do that, but better safe than sorry.

[dudk]

Thank you for your contribution @vsariola!