Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <3E777EB2.2050305@Hp.com>
Date: Tue, 18 Mar 2003 15:16:50 -0500
User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.3a) Gecko/20021217
Mime-Version: 1.0
To: internals@lists.php.net
Cc: hirokawa@php.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: more 6 bit issues - mbstring
From: David.Hill@Hp.com (Dave Hill)



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