64-bit bugsquash

php.internals

Ard Biesheuvel

22 years ago
Would anyone with Zend karma care to commit this ?
-- Ard Index: zend_builtin_functions.c =================================================================== RCS file: /repository/ZendEngine2/zend_builtin_functions.c,v retrieving revision 1.237 diff -u -r1.237 zend_builtin_functions.c --- zend_builtin_functions.c 28 May 2004 08:08:56 -0000 1.237 +++ zend_builtin_functions.c 17 Jun 2004 09:18:03 -0000 @@ -805,7 +805,7 @@ { char *class_name, *lc_name; zend_class_entry **ce; - long class_name_len; + int class_name_len; zend_bool autoload = 1; int found;

Sara Golemon

22 years ago
committed in ZE2. MFH not needed since this method in ZE1 uses zend_get_parameters. "Ard Biesheuvel" <abies@php.net> wrote in message news:40D16253.4000003@php.net...

Alexander Valyalkin

22 years ago
There is a header file with PHP type's definition: /Zend/zend_types.h It consists following types: ------------------------------- typedef unsigned char zend_bool; typedef unsigned char zend_uchar; typedef unsigned int zend_uint; typedef unsigned long zend_ulong; typedef unsigned short zend_ushort; ------------------------------- I propose to add several new types with EXACT bit length into this file: ------------------------------- typedef __int8 zend_int8; typedef __int16 zend_int16; typedef __int32 zend_int32; typedef __int64 zend_int64; typedef unsigned __int8 zend_uint8; typedef unsigned __int16 zend_uint16; typedef unsigned __int32 zend_uint32; typedef unsigned __int64 zend_uint64; ------------------------------- If compiler does not support some __int* types, (for example, __int64), we can deal it before zend_* types definition. For example: ------------------------------------- #ifdef COMPILERS_WITHOUT_INT64_TYPE typedef long long __int64; #endif ------------------------------------- Then in other places of PHP sources: - if we need EXACT 8bit integers, we must use zend_int8 type - if we need EXACT 16bit integers, we must use zend_int16 type. etc... It solves such problems as "int is 64bit on FOO compiler" or "long is 32bit on BAR compiler".
-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Stefan Esser

22 years ago
Alexander Valyalkin wrote:
> I propose to add several new types with EXACT bit length into this file: > ------------------------------- > typedef __int8 zend_int8; > typedef __int16 zend_int16; > typedef __int32 zend_int32; > typedef __int64 zend_int64; > typedef unsigned __int8 zend_uint8; > typedef unsigned __int16 zend_uint16; > typedef unsigned __int32 zend_uint32; > typedef unsigned __int64 zend_uint64; > -------------------------------
Sorry but this idea is out of question. The idea was always that PHP is 64 bit capable as soon you run it on a 64 bit machine. Same for 128 bit machines in the future. It is a stupid idea to limit the number of bits. Especially if you have to call libc functions... Stefan Esser

Ard Biesheuvel

22 years ago
The problem with ints and longs is not their sizes, but the fact that people use them interchangeably, their sizes being equal coincidentally on 32-bit architectures. Most of the bugs occur when pointers to these variables are passed as arguments to variadic functions like zend_parse_parameters(), which are not subject to pointer type checking by the compiler.
> Sorry but this idea is out of question. The idea was always that PHP is > 64 bit capable as soon you run it on a 64 bit machine. Same for 128 bit
Some data structures [like IPv4 addresses, for instance], are 32-bits regardless of the architecture, so some code needs its variable sizes to be defined explicitly. Defining intxx types might be useful in this respect, but it won't fix the problem mentioned before.
>> typedef __int8 zend_int8; >> typedef __int16 zend_int16; >> typedef __int32 zend_int32; >> typedef __int64 zend_int64; >> typedef unsigned __int8 zend_uint8; >> typedef unsigned __int16 zend_uint16; >> typedef unsigned __int32 zend_uint32; >> typedef unsigned __int64 zend_uint64;
Arent't the __intxx types MSVC-only ?
-- Ard