On Fri, 19 Oct 2001, Stig S. Bakken wrote: > 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.
I like this idea... But when you do (int)$bla, you really expect an integer... and not null. Still, is null maybe acceptable? Zeev&Andi? This reminds me of another suggesting I made: the (number) cast. It will convert to int if possible, float otherwise. Third point: Currently casting array to a number, it will be 1 if non-empty, zero if empty. IMHO, it is more logical to simply return the number of elements. It is BC, since boolean checks for array will still yield false iff array is empty. (I'm - of course - open for discussion on these things) --Jeroen > > - 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 > 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]
