Re: NAN and INF cast to int

On 1/2/14, 10:36 AM, Robert Stoll wrote: > Another behaviour which I find strange is that a division by 0 yields false and not NAN: > var_dump(1.5/0) ; // boolean false > > I am aware of that introducing an E_WARNING would be somewhat a BC break but I still suggest to > consider it because I > rather see it as a bug. Consider the following example: > $f = INF; //somehow INF was assigned to $f at some point > $g = $f - 1; //$g is still INF -> correct IMO > $h = (int) $g; // $i = 0; -> the value as such is ok IMO but it should trigger an E_WARNING > $i = $h - 1; //$i = -1 -> especially hard to detect if one does further calculations with > such a value Are you testing on Windows? Things are a little odd there with its 32-bit ints on a 64-bit OS. There is a lot of work going on right now to clean up the Windows situation. (int)INF is not 0 on 64-bit Linux. INF/NAN convert to 0x8000000000000000 if you force a cast which is why when you cast it to bool you get true. The reason for 0x8000000000000000 is not a PHP thing but an x86-64 convention. This value is the indefinite integer value and basically just tells you that you performed an action that is not defined. And given that it is not defined, you cannot rely on the behaviour which might be why on your platform you are getting zero. Although the subsequent casts you show indicate it isn't actually zero. I don't see anything incorrect here, but I agree we probably could add an E_WARNING to some of these edge cases in addition to the one we have for division by zero. -Rasmus

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc