Greetings,
I have encountered a 64 bit issue with ext/mbstring that I would like to share with the list. I am not trying to pick on mbstring, it just was unfortunate enough to be the place where I first encountered the bug. This gives me yet another chance to help educate folks on how to write 64 bit capable code.
I refer to this as the 'infamous int filter bug".
remember on all 64 bit platforms I know about:
sizeof(int) == 4 // 32 bits
sizeof(long) == 8 // 64 bits
sizeof(void *) == 8 // pointers are 64 bits
On the two platforms I have imediate access to - all allocated memory by deafult has at least one bit set in the upper 32 bits of the address - exactly to expose the types of bugs I am explaining here.
For example: char * c; int i;
c = (char *)malloc(50); // get me a pointer - 64 bits
i = (int) c; // stuff that pointer into an int - 32 bits
c = (char *)i; // try to get the pointer back
This is toxic ! The resulting pointer has been clipped to 32 bits and should SEGV as soon as it is accessed.
If you must use a integer type variable to hold a pointer it must be a long an not an int. It is also reasonable to use an int as a offet to a pointer, but never to hold the full value.
A dead giveaway to the problem is:
i = (int) malloc(x);
Unfortunately, ext/mbstring has lots of uses of int where a long would have been better, and I think that the extent of changes will need to be done by the module maintainer because short of changing all ints to longs I am not sure where to begin. This is especially true given the README in there that says the code is being reworked.
Dave
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
