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