Re: [DRAFT][RFC] Big Integer Support

Hello, I’ve made a change to the RFC and patch, whereby NaN will cast to integer zero instead of LONG_MIN. I think that makes a lot more sense and I haven’t put this under “Open Questions” as I don’t think anyone will really object. Also, I’m reconsidering my earlier position on how to handle bigint to long casting. (Userland can’t cast to long, but zend_parse_parameters, bitwise shifts etc. need to use zend_dval_to_lval sometimes.) While I have currently made the patch cap the value at the maximum/minimum value if too large/small, this is inconsistent with double to long casting which instead truncates and preserves the lowest bits. For this reason, and because I think it’s better to keep as much information as possible rather than lose everything but the sign, I will change it to truncate. Either way, I think there should be some sort of warning (probably an E_NOTICE or E_WARNING?) when this cast happens implicitly and the number is truncated, such as in function calls. I’m tempted to remove this from Open Questions and instead just Do The Right Thing and if someone objects later, the patch and RFC can always be changed. Of course, it’s worth noting we currently *don’t* do any sort of warning when casting a float to a long causes a loss of information. Anthony Ferrara’s sadly withdrawn RFC for scalar type hints would have done this for user land functions, but that hasn’t happened yet, so adding a warning here would be inconsistent with floats. Any thoughts? Thanks! -- Andrea Faulds http://ajf.me/