Re: cvs: php-src / README.PARAMETER_PARSING_API /win32/build config.w32 ZendEngine2 Zend.m4 zend_API.c zend_compile.c zend_execute.c
zend_execute_API.c zend_operators.c zend_operators.h zend_vm_def.h zend_vm_execute.h
| From: | Matt Wilmas | Date: | Thu, 04 Jun 2009 18:45:29 +0000 |
| Subject: | Re: cvs: php-src / README.PARAMETER_PARSING_API /win32/build config.w32 ZendEngine2 Zend.m4 zend_API.c zend_compile.c zend_execute.c zend_execute_API.c zend_operators.c zend_operators.h zend_vm_def.h zend_vm_execute.h |
||
| References: | 1 2 | Groups: | php.cvs php.internals |
| Request: | Send a blank email to internals+get-44159@lists.php.net to get a copy of this message | ||
Hi Andrei,
----- Original Message -----
From: "Andrei Zmievski"
Sent: Thursday, June 04, 2009
Hmm, can we use something other than L? We were hoping to reserve L for use in PHP 6 for bigint numbers.Sure! It makes no difference to me at all. Should I just remove that part completely? I didn't know if it would even be used -- just thinking more of "it's there if someone wants the option..."
-Andrei- Matt
Matt Wilmas wrote:mattwil Thu Jun 4 18:18:47 2009 UTCModified files: /php-src README.PARAMETER_PARSING_API /ZendEngine2 Zend.m4 zend_API.c zend_compile.c zend_execute.c zend_execute_API.c zend_operators.c zend_operators.h zend_vm_def.h zend_vm_execute.h /php-src/win32/build config.w32 Log: Restored double->long conversion behavior to that of PHP 5.2 (on most platforms) and prior: * Out-of-range numbers overflow/preserve least significant bits (no LONG_MAX/MIN limit) * See bug #42868 (presumably-rare platform with different results in 5.2) * On 32-bit platforms with 64-bit long type, a zend_long64 cast has been added, otherwise it's the same as 5.2 * Use this conversion method everywhere instead of some plain (long) castsAdded 'L' parameter parsing specifier to ensure a LONG_MAX/MIN limit: * Essentially what 5.3's new conversion was doing in most cases * Functions with "limit" or "length" type params could be updated to use this,and prevent confusing overflow behavior with huge numbers (*also* in 5.2) - See bug #47854, for example; or even #42868 again# Test updates coming