stasMon Oct 10 14:32:31 2005 EDT
Modified files: (Branch: PHP_5_0)
/php-src/ext/standard php_incomplete_class.h
Log:
MFH 64-bit fix
http://cvs.php.net/diff.php/php-src/ext/standard/php_incomplete_class.h?r1=1.13.2.2r2=1.13.2.3ty=u
Index:
Hello Stanislav,
how the hell is this commit a fix?
size_t is a specialized typedef for the exact purpose, being capable of
handling any size a pointer can store. If this patch now solves anything
for you then most probably we have thousands of potential 64bit memory
corruption issues. Or
MBsize_t is a specialized typedef for the exact purpose, being capable of
MBhandling any size a pointer can store.
Right.
MBfor you then most probably we have thousands of potential 64bit memory
MBcorruption issues. Or sizeof(zend_uint) is bigger then sizeof(size_t)
MBwhich is then only a
hi,
furthermore are you aware that there are several fixes that are also not
applied to 5.0.x (atleast I know for sure that several streams fixes
fall into this category). I really dont see the point in doing more
5.0.x releases if they dont fix countless bugs that are marked as fixed
in
LKSfurthermore are you aware that there are several fixes that are also
LKSnot applied to 5.0.x (atleast I know for sure that several streams
LKSfixes fall into this category). I really dont see the point in doing
LKSmore 5.0.x releases if they dont fix countless bugs that are marked
LKSas
Hello Stanislav,
Monday, October 10, 2005, 9:05:05 PM, you wrote:
MBsize_t is a specialized typedef for the exact purpose, being capable of
MBhandling any size a pointer can store.
Right.
MBfor you then most probably we have thousands of potential 64bit memory
MBcorruption issues. Or
MB Yes, it is. So you can not use address of size_t instead as zend_uint *,
because
MB when you assign uint *, part of size_t remains unassigned. This is the
MB source of the bug.
MB
MBThen why don't fix the bug but instead change some valid code?
I fixed the bug. The bug was exactly to define
Hello Stanislav,
ok, a short lookup showed that we indeed save the length information in the
class as zend_uint. This is wrong since both strlen() and sizeof() return
size_t and both are used on the registering part. Thus the origin is already
wrong.
marcus
Monday, October 10, 2005, 9:17:33
MBclass as zend_uint. This is wrong since both strlen() and sizeof()
MBreturn size_t and both are used on the registering part. Thus the
MBorigin is already wrong.
ZE uses uints for key lengthes in all places. The fact that strlen and
sizeof() return size_t is of purely theoretical interest
Hello Stanislav,
right and probably wrong alsonoone will ever use more than 640K RAM...
ok
marcus
Monday, October 10, 2005, 11:52:40 PM, you wrote:
MBclass as zend_uint. This is wrong since both strlen() and sizeof()
MBreturn size_t and both are used on the registering part. Thus the
johannesWed Jun 29 05:29:08 2005 EDT
Modified files: (Branch: PHP_5_0)
/php-src/ext/standard php_incomplete_class.h
Log:
- MFH: Fix TSRM build
http://cvs.php.net/diff.php/php-src/ext/standard/php_incomplete_class.h?r1=1.13.2.1r2=1.13.2.2ty=u
Index:
stasTue Jun 28 05:17:21 2005 EDT
Modified files: (Branch: PHP_5_0)
/php-src/ext/standard var.c php_incomplete_class.h
Log:
fix non-PHP object handling (from John Coggeshall)
12 matches
Mail list logo
