Re: Integer operations are implementation-defined

On 1 Aug 2014, at 06:02, Stas Malyshev <smalyshev@sugarcrm.com> wrote: >> This wouldn’t close the door to them IMO, it just means that PHP >> can’t have them for 5.6, and I think that’s reasonable. I suppose you > > OK, if we follow 5.6, and I think it makes sense to, then indeed we > should write what 5.6 does, and if we change it in 7.0 we can update the > spec to version 2.0 just as other languages do :) My thoughts exactly. > So let's follow 5.6 unless there's a very good reason not to (e.g. some > behavior that is kept around only for BC or other like reasons and that > we actually don't like so we want to allow others to get rid of it). Right. I’ve made an initial pull request to change how integer overflow is defined: https://github.com/php/php-langspec/pull/36 It also now stipulates integers must be fixed-size, because this makes no real sense if they aren’t. However, that pull request isn’t quite complete as I need to look into also specifying the int->float and float->int conversion rules on overflow. It’s currently completely implementation-defined if the float is out of the range of the int, or vice versa, which is bad as you can’t depend on that. While NAN and INF are sadly undefined and will have to stay that way for now (php.net PHP behaviour here depends on the platform), php.net PHP has a well-defined and predictable casting rule which, if not natively supported, is actually done in software explicitly with fmod(). I don’t actually understand the behaviour just now, and I need to look into how it works anyway because of my bigints patch, so that’s my project for today. Actually, this isn’t a specification thing specifically, and I know PHP 5.6 is in feature freeze and nearing release, but we should really add the PHP_INT_MIN constant by now. Having to write (-PHP_INT_MAX - 1) everywhere isn’t good, and loads and loads of tests and userland code has to do this. Would Ferenc permit this as a special exception? -- Andrea Faulds http://ajf.me/