<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px"><div id="yui_3_16_0_ym19_1_1500230760472_15287">> The "bad" behavior is that, fro instance, 0 in gives 1 out. That happened <br></div><div id="yui_3_16_0_ym19_1_1500230760472_15286">on everyone's machine except mine (so I was blissfully unaware that anything <br></div><div id="yui_3_16_0_ym19_1_1500230760472_15285">was wrong). I'm running fedora linux. Even debian linux machines gave the <br></div><div id="yui_3_16_0_ym19_1_1500230760472_15284">wrong answer while my machine kept giving me the right one. Im not going <br></div><div id="yui_3_16_0_ym19_1_1500230760472_15405">to try to figure out what the #$&^ was going on :)<br></div><div id="yui_3_16_0_ym19_1_1500230760472_15283"><br></div><div id="yui_3_16_0_ym19_1_1500230760472_15406">If someone can point clearly to the source of undefined behavior in that <br></div><div id="yui_3_16_0_ym19_1_1500230760472_15442" dir="ltr">seemingly simple code then it would seem appropriate to just fix the bug <br></div><div dir="ltr">and move on.<br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1500230760472_15618"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1500230760472_15619">Otherwise it appears to be deterministic bug (excepting one unexplained <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1500230760472_15882">edge case) that almost certainly has resulted in patches out in the wild behaving <br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1500230760472_15883">and/or sounding one way and not another. A compatibility case seems </div><div dir="ltr" id="yui_3_16_0_ym19_1_1500230760472_15884">warranted for this.</div><div dir="ltr" id="yui_3_16_0_ym19_1_1500230760472_15885"><br></div><div dir="ltr" id="yui_3_16_0_ym19_1_1500230760472_15915">-Jonathan<br></div><div id="yui_3_16_0_ym19_1_1500230760472_15282"><br></div><div id="yui_3_16_0_ym19_1_1500230760472_15281">> M<br clear="none"></div><div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1500230760472_15193" style="display: block;"><div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 13px;" id="yui_3_16_0_ym19_1_1500230760472_15192"><div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1500230760472_15191"><div class="y_msg_container" id="yui_3_16_0_ym19_1_1500230760472_15195"><div class="yqt6315367012" id="yqtfd62447"><br clear="none">On Sun, Jul 16, 2017 at 06:51:03PM +0000, Jonathan Wilkes via Pd-list wrote:<br clear="none">> > That's just the question - is it worth keeping an old bug available for <br clear="none">> compatibility? In this case, perhaps yes - although you'd have to <br clear="none">> explicitly set a compatibility flag in Pd to get eh old behavior.<br clear="none">> <br clear="none">> > (incidentally teh old behavior was machine-dependent - this complicates it <br clear="none">> even further :)<br clear="none">> I didn't notice that it's machine-dependent-- it just appears as the wrong algorithm <br clear="none">> to me.<br clear="none">> <br clear="none">> Is there undefined behavior there?<br clear="none">> -Jonathan<br clear="none"><br clear="none">> _______________________________________________<br clear="none">> <a shape="rect" ymailto="mailto:Pd-list@lists.iem.at" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">> UNSUBSCRIBE and account-management -> <a shape="rect" href="https://lists.puredata.info/listinfo/pd-list" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br clear="none"><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>