<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-02-11 23:57 GMT+01:00 Nicolas Cellier <span dir="ltr">&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Some C functions in libm only take an int, not a long.<br>In 32 bits int=long, so no problem.<br>In 64 bits generally int=32 bits, long=64 bits, so casting a long to int might lead to catastrophic loss and unexpected behavior.<br><br>This is the case for example in primitiveTimesTwoPower<br>    | rcvr arg |<br>    &lt;var: #rcvr type: #double&gt;<br>    arg := self popInteger.<br>    rcvr := self popFloat.<br>    self successful<br>        ifTrue: [ self pushFloat: (self cCode: &#39;ldexp(rcvr, arg)&#39; inSmalltalk: [rcvr timesTwoPower: arg]) ]<br>        ifFalse: [ self unPop: 2 ]<br><br>arg will be a long in Spur64, won&#39;t it?<br>but ldexp only takes an int<br>    double ldexp(double x, int exp);.<br><br>So guess what if we call (1.0 timesTwoPower: 16r10000000001)... <br>Normally there should be a C compiler warning, and we should care of it.<br><br></div>To solve this, maybe we need a<br>    <br>    &lt;var: #arg type: #int&gt;<br></div>    arg := self signed32BitValueOf: stackTop.<br></div></blockquote><div><br></div><div>of course, it&#39;s the same for primitiveSmallFloatTimesTwoPower (where things will really happen most of the time in Spur64) <br></div></div><br></div></div>