# 64-bit bugsquash - Thread: https://externals.io/message/10565 - Original archive: https://news-web.php.net/php.internals/10565 - Started by Ard Biesheuvel on 2004-06-17T09:20:19+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #10565 — Ard Biesheuvel — 2004-06-17T09:20:19+00:00 URL: https://externals.io/message/10565#10565 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; --- ## #10572 — Sara Golemon — 2004-06-17T18:28:23+00:00 URL: https://externals.io/message/10565#10572 · In reply to: #10565 committed in ZE2. MFH not needed since this method in ZE1 uses zend_get_parameters. "Ard Biesheuvel" wrote in message news:40D16253.4000003@php.net... > > 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; --- ## #10582 — Alexander Valyalkin — 2004-06-18T08:08:54+00:00 URL: https://externals.io/message/10565#10582 · In reply to: #10565 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/ --- ## #10595 — Stefan Esser — 2004-06-18T18:14:43+00:00 URL: https://externals.io/message/10565#10595 · In reply to: #10582 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 --- ## #10610 — Ard Biesheuvel — 2004-06-18T20:08:16+00:00 URL: https://externals.io/message/10565#10610 · In reply to: #10595 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. > > […] Arent't the __intxx types MSVC-only ? -- Ard