Hi, Preface: This e-mail uses the distribution list (To and CC addresses) that the original poster used. I have moved everyone other than php-dev to Bcc so that this doesn't get perpetuated (I have no idea of the significance of the other addresses that were e-mailed, nor do I know Dave Hill's standing in the PHP community).
In message <[EMAIL PROTECTED]> on Thu, Feb 27, 2003 at 02:52:28PM -0500, Dave Hill wrote: > Proposed Patch to address 64 bit issues in PHP v4.3.1 > Diff -u against php4-STABLE-200302241430 > Also needed in 4.5.x and 5.x > Addresses bugs 20994, 21002, 21822, 20268 There was some discussion on php-dev in November 2002 after I posted patches for bug #20268 (the earliest-numbered one in Dave's list). > I chose to address this problem by creating OnUpdateLong (in addition to > to existing OnUpdateInt) and sweep though the code changing the call > where needed to match the stucture item. An equally valid fix would be > to change all of those longs to ints. (a) I also chose to create OnUpdateLong (and this has been working well for me since 4.3.0pre2 using the patches I posted). Since I posted those patches, PHP has progressed and more of these problems have been introduced (bad) but at the same time some of the test cases have been revised to be more portable (good). (b) I found that sometimes ints needed to stay as ints and longs needed to stay as longs, which is why I chose to separate OnUpdateLong from OnUpdateInt. (c) In discussions on php-dev in November, the subject of the thread was "64-bit PHP 4.3 (extensive long vs int problems)" <http://marc.theaimsgroup.com/?t=103690291000001&r=1&w=2> (d) Jason Greene responded as a person who was working on this problem. Disfavour of the OnUpdateLong solution was expressed (on- and maybe off-list, too). > After performing that sweep, I found there was a small number of other > errors of the int/long type that my compiler found that I corrected and > are included here. There might be more mix and match problems, I only > addressed the ones in the modules I have enabled. Deja vu! Now the reason I am responding and the reason I have BCCed the people in Dave's list was that I wanted to mention something about Zend. Really, this bug has its roots in Zend though it is manifested in PHP modules. Firstly, OnUpdateInt assigns to long storage but uses zend_atoi -- clearly there is confusion already. But the more disturbing thing that I found in November was the Zend documentation for zend_parse_parameters (a site of extensive long/int problems). That is why I have written this e-mail. I know nothing about the Zend engine but I will refer to this document: <http://www.zend.com/apidoc/zend.arguments.retrieval.php> It is entitled "Accepting Arguments / Retrieving Arguments" and describes the zend_parse_parameters function. It lists a type specifier: "l - long" But it does not list an int type. In the actual code, it is entirely long-based, not int-based, so there is clearly a mismatch. But moreover, there is no acknowledgement of the significance of int versus long. So it is not surprising that so many developers have made mistakes arising from this. Therefore, I thought that a proper solution to this problem would have to involve some consideration of the Zend API (or at least copious acknowledgments and warnings in its documentation). There is potentially a huge developer education problem, too. That is why I chose to add OnUpdateLong. And given the choice, I would have 'i - int' added to the type specifiers of zend_parse_parameters. Firstly, having the OnUpdateLong function allows quick rectification of these problems without having to try to stuff ints into longs or longs into ints -- we can instead just choose the one that fits the task. Moreover: by having two functions and two type specifiers (one for ints and one for longs), the situation would almost be self-documenting: developers that would usually neglect to consider the difference between int and long would at least see that there is a 'int' variant and a 'long' variant and therefore be prompted -- without extensive re-education -- to consider using the correct 'hole' for the 'peg'. If Zend is to settle on everything being longs or everything being ints, then people have to be stopped from reintroducing the 'wrong' type and people are going to have problems when the 'other' storage is the only one that appears to fit the job. Given the gradual divergence of Zend & PHP from 64-bit cleanliness, I had thought these things to be fairly urgent and fundamental. In any case, the number of users and lines of code influenced by these issues has become increasingly visible in public over the last four months. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
