The "bad" behavior is that, fro instance, 0 in gives 1 out. That happened
on everyone's machine except mine (so I was blissfully unaware that anything was wrong). I'm running fedora linux. Even debian linux machines gave the wrong answer while my machine kept giving me the right one. Im not going to try to figure out what the #$&^ was going on :)
If someone can point clearly to the source of undefined behavior in that seemingly simple code then it would seem appropriate to just fix the bug and move on.
Otherwise it appears to be deterministic bug (excepting one unexplained edge case) that almost certainly has resulted in patches out in the wild behaving and/or sounding one way and not another. A compatibility case seems warranted for this. -Jonathan
M
On Sun, Jul 16, 2017 at 06:51:03PM +0000, Jonathan Wilkes via Pd-list wrote:
That's just the question - is it worth keeping an old bug available for
compatibility? In this case, perhaps yes - although you'd have to explicitly set a compatibility flag in Pd to get eh old behavior.
(incidentally teh old behavior was machine-dependent - this complicates it
even further :) I didn't notice that it's machine-dependent-- it just appears as the wrong algorithm to me.
Is there undefined behavior there? -Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list