Joe,
This may be crazy, but does it make sense to think of integers in a more defined manner? That is, ``integer'' being equivalent to a long, which does have a guarantee on size (32-bit)? Also, some kind of long long type for 64-bit support would have to be included. I mean, consistency is something I value... Does it make sense to just be pragmatic and switch over to defined/guaranteed sizes/behavior, rather than hoping and bailing out under the ``platform-defined'' clause? Is this at all applicable?
Thanks, -Noah
Joe Orton wrote:
On Tue, Oct 05, 2004 at 05:12:36PM -0700, Andi Gutmans wrote:
At 02:17 PM 10/5/2004 +0200, Edin Kadribasic wrote:
On Tuesday 05 October 2004 14:02, Derick Rethans wrote:
On Tue, 5 Oct 2004, Wez Furlong wrote:
Feels like a major bug to me... this got into a release? :-/
Yes, please keep the discussion about this in the bugreport, and not on the list.
This is exactly the place where things like this should be discussed.
Isn't this behavior changed by Joe Orton's patch to eliminate "undefined compiler behavior"? Breaking BC like this should always be avoided and I vote for reverting that particular fix if it indeed is resposnsible for this problem.
Yes I agree. The question is how do we revert and deal with Joe's problems at the same time?
Well, I can be theoretical:
The behaviour of PHP in handling of this conversion was never well
defined. The script given in the bug report will already behave
differently for builds PHP 4.3.9 on different platforms (32-bit vs
64-bit). I think this weakens the "backwards compatibility" argument. PHP did not guarantee a particular behaviour, and the behaviour already
differed across platforms, and now also across releases.
Maintaining the old behaviour in conformant C code is tricky or impossible depending on how you look at it, given that it was determined purely by C compiler and platform.
... or I can be practical:
just revert the changes in the stable branches (I didn't particular expect it to show up there in the first place). I only looked at this code because it was triggering a GCC bug, which is now fixed.
joe
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
