This very simple external provides a responder to a single message, "test". The object's data structure extends t_object by a single integer, "pad". I set "pad" to zero immediately after pd_new(). Later, when it receives "test", it prints "pad" again. On Linux, the log contains the following:
hello_new, x->pad: 0
hello_test, x->pad: 0
However, on Windows, the log contains this:
hello_new, x->pad: 0
hello_test, x->pad: 0x1
This means somewhere between initializing my object and receiving "test", the t_object structure is written to beyond its length.
This was noticed because in a real object I had a pointer in that location, which was invalidated by this effect, and dereferencing it caused PureData to crash. My temporary solution is to put a padding int there, but it would be nice to find the problem. I haven't yet managed to compile Pd from scratch for Windows yet, so I can't debug it until I get that working, but I thought I should report it in case anyone knows more.
Anonymous
Simple "test" responder that demonstrates the problem.
Forgot to add that this behaviour was noticed on the most recent downloads of both Pd-extended and PureData vanilla.