> 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