On Fri, 19 Oct 2001, Stig S. Bakken wrote: > In cases like these I think PHP should do whatever C does. There's no > point in trying to be clever when casts overflow.
In C, when you doe int i;, i will contain random data. In PHP, a variable will always be cleared (to null). In C, when you cast a out-of-range-float, I doubt wether it's defined. Furthermore, PHP is not C, so I see no reason to follow C just like that. What do you expect from trying to store a too big float in an integer? I expect an error, and the nearest valid result. I really see no logic in the current behavior, only that it makes a limited amount of unsigned-int faking possible. But floats are floats, that's not going well all the time (see the numerous bugreports on this kind of gotcha's). So also for this reason I believe there should be no such wrapping behaviour, as it might lead people to think unsigned ints are supported, resulting in very strange things. Especially the E_NOTICE when this happens will help a lot of people IMO. In the case of casting larger integers into smallers, it's differnt because you're talking about _intgers_ then, and not floats. --Jeroen > > - Stig > > Jeroen van Wolffelaar wrote: > > > > Resent, due to lack of feedback from my side ;) > > > > Andi replied: > > >> > > Why is it more correct to convert it to min/max values? I can't think of a > > case where this would make more sense to the developer. > > Also, there is a reason for the cast to unsigned int if the value is bigger > > that LONG_MAX. > > << > > > > I think it makes sense. If a float is out-of-range, it can usually not be > > mod'd by 2**32, due to the nature of floats. Therefore, the only consistent > > way would be going to the nearest integer possible. > > > > Okay, because on most systems floats happen to be more precise than int's, > > you _can_ mod them by 2**32, but there is a quite significant possibility of > > having rounding errors. You cannot do integer-precision with floats. > > > > And it's inconsistent too, PHP int's are ranging from -2**31 to (2**31)-1, > > there is no such thing as unsigned integers. So why convert the float 3e9 to > > something way below zero? > > > > Additionally, a notice is a good idea here, just like what happens on > > division by zero: the most natural result is returned, and a notice is > > issued. > > > > --Jeroen > > > > ----- Original Message ----- > > From: "Jeroen van Wolffelaar" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, October 02, 2001 2:39 AM > > Subject: [PATCH] Fix for inconsistent float->int converting > > > > > When a too-large float is converted to integer, it happens in a quite > > > random way. When float is out of range, PHP should stick to the min > > > resp. max values of integer. > > > > > > This patch will achieve this, I tested it succesfully. > > > > > > --Jeroen > > > > > > Jeroen van Wolffelaar > > > [EMAIL PROTECTED] > > > http://www.A-Eskwadraat.nl/~jeroen > > > > > > > ------------------------------------------------------------------------ > > Name: double.diff > > double.diff Type: unspecified type (application/octet-stream) > > Encoding: quoted-printable > > > > ------------------------------------------------------------------------ > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > To contact the list administrators, e-mail: [EMAIL PROTECTED] > Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
