Hm, another way to deal with overflows could be returning null, if it's acceptable to return a different type than expected at least. With 0 or max/min, it won't be possible for a program to detect overflows. With null it would be.
- Stig Jeroen van Wolffelaar wrote: > > 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]
