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
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
In cases like these I think PHP should do whatever C does. There's no
point in trying to be clever when casts overflow.
- 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
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
I just did some checking, this behaviour is not defined in C, and even
in C99 it's in the twilight zone if you can define this at all.
The common thing seems to be throwing an exception if an overflow
occurs. Since PHP doesn't have exceptions yet that's a notice or maybe
even warning for us
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,
