#50148 [NEW]: [PATCH] - zend_get_property_info should check for Z_TYPE_P(member) == IS_STRING
From: yoarvi at gmail dot com
Operating system: Solaris 10/SPARC
PHP version: 6SVN-2009-11-11 (SVN)
PHP Bug Type: Unicode Engine related
Bug description: [PATCH] - zend_get_property_info should check for
Z_TYPE_P(member) == IS_STRING
Description:
When I ran 'gmake test' on my PHP6 tree on Solaris 10 (SPARC), I noticed
many test failures.
The following patch fixes many(~350) of these test failures:
Index: Zend/zend_object_handlers.c
===
--- Zend/zend_object_handlers.c (revision 290471)
+++ Zend/zend_object_handlers.c (working copy)
@@ -198,7 +198,7 @@
ulong h;
if ((Z_TYPE_P(member) == IS_UNICODE && Z_USTRVAL_P(member)[0] ==
0) ||
- Z_STRVAL_P(member)[0] == '\0') {
+ (Z_TYPE_P(member) == IS_STRING && Z_STRVAL_P(member)[0] ==
'\0')) {
if (!silent) {
if (Z_UNILEN_P(member) == 0) {
zend_error(E_ERROR, "Cannot access empty
property");
Reproduce code:
---
% sapi/cli/php tests/classes/__call_001.php
Expected result:
Method test called:
array(4) {
[0]=>
int(1)
[1]=>
unicode(1) "2"
[2]=>
float(3.4)
[3]=>
bool(true)
}
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
Actual result:
--
Method test called:
array(4) {
[0]=>
int(1)
[1]=>
unicode(1) "2"
[2]=>
float(3.4)
[3]=>
bool(true)
}
Fatal error: Cannot access property started with '\0' in
/space/arvind/php-src-6/tests/classes/__call_001.phpt on line 14
--
Edit bug report at http://bugs.php.net/?id=50148&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50148&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50148&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50148&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50148&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50148&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50148&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50148&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50148&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50148&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50148&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50148&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50148&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50148&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50148&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50148&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50148&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50148&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50148&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50148&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50148&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50148&r=mysqlcfg
#50189 [NEW]: [PATCH] - unicode byte order difference between SPARC and x86
From: yoarvi at gmail dot com
Operating system: Solaris 10 (SPARC)
PHP version: 6SVN-2009-11-16 (SVN)
PHP Bug Type: Unicode Function Upgrades related
Bug description: [PATCH] - unicode byte order difference between SPARC and x86
Description:
zspprintf() incorrectly represents strings/chars as unicode characters on
Solaris (SPARC).
There are byte ordering differences for unicode representations between
x86 and SPARC:
For example, the unicode representation (i've grouped them in sets of
2chars) of '/tmp' on x86 is
'/''\0' 't''\0' 'm''\0' 'p''\0'
and on SPARC it is
'\0''/' '\0''t' '\0''m' '\0''p'
http://marc.info/?l=php-internals&m=125811990106419&w=2 has some more
details.
the problem seems to be in the smart_str_append2c macro that
zspprintf()/xbuf_format_converter end up using.
The following patch fixes the problem:
Index: ext/standard/php_smart_str.h
===
--- ext/standard/php_smart_str.h(revision 290471)
+++ ext/standard/php_smart_str.h(working copy)
@@ -86,10 +86,17 @@
smart_str_appendc_ex((dest), (c), 0)
/* appending of a single UTF-16 code unit (2 byte)*/
+#if (defined(i386) || defined(__i386__) || defined(_X86_))
#define smart_str_append2c(dest, c) do { \
smart_str_appendc_ex((dest), (c&0xFF), 0); \
smart_str_appendc_ex((dest), (c&0xFF00 ? c>>8 : '\0'), 0); \
} while (0)
+#else
+#define smart_str_append2c(dest, c) do { \
+ smart_str_appendc_ex((dest), (c&0xFF00 ? c>>8 : '\0'), 0); \
+ smart_str_appendc_ex((dest), (c&0xFF), 0); \
+} while (0)
+#endif
#define smart_str_free(s) \
smart_str_free_ex((s), 0)
Reproduce code:
---
% sapi/cli/php ext/spl/tests/DirectoryIterator_getBasename_basic_test.php
Expected result:
getBasename_test
Actual result:
--
php goes into an infinite loop
--
Edit bug report at http://bugs.php.net/?id=50189&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50189&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50189&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50189&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50189&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50189&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50189&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50189&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50189&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50189&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50189&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50189&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50189&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50189&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50189&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50189&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50189&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50189&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50189&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50189&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50189&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50189&r=mysqlcfg
#50189 [Opn]: [PATCH] - unicode byte order difference between SPARC and x86
ID: 50189
User updated by: yoarvi at gmail dot com
Reported By: yoarvi at gmail dot com
Status: Open
-Bug Type: Unicode Function Upgrades relate
+Bug Type: *General Issues
Operating System: Solaris 10 (SPARC)
PHP Version: 6SVN-2009-11-16 (SVN)
New Comment:
ext/sqlite3/libsqlite/sqlite3.c uses
#if defined(i386) || defined(__i386__) || defined(_M_IX86)\
|| defined(__x86_64) ||
defined(__x86_64__)
Is that better?
Previous Comments:
[2009-11-16 13:07:50] tokul at users dot sourceforge dot net
If is not "#if (defined(i386) || defined(__i386__) || defined(_X86_))
" vs others.
It is little endian vs big endian. I suspect that code should not
assume that all other archs are big endian.
[2009-11-16 12:20:44] yoarvi at gmail dot com
Description:
zspprintf() incorrectly represents strings/chars as unicode characters
on Solaris (SPARC).
There are byte ordering differences for unicode representations between
x86 and SPARC:
For example, the unicode representation (i've grouped them in sets of
2chars) of '/tmp' on x86 is
'/''\0' 't''\0' 'm''\0' 'p''\0'
and on SPARC it is
'\0''/' '\0''t' '\0''m' '\0''p'
http://marc.info/?l=php-internals&m=125811990106419&w=2 has some more
details.
the problem seems to be in the smart_str_append2c macro that
zspprintf()/xbuf_format_converter end up using.
The following patch fixes the problem:
Index: ext/standard/php_smart_str.h
===
--- ext/standard/php_smart_str.h(revision 290471)
+++ ext/standard/php_smart_str.h(working copy)
@@ -86,10 +86,17 @@
smart_str_appendc_ex((dest), (c), 0)
/* appending of a single UTF-16 code unit (2 byte)*/
+#if (defined(i386) || defined(__i386__) || defined(_X86_))
#define smart_str_append2c(dest, c) do { \
smart_str_appendc_ex((dest), (c&0xFF), 0); \
smart_str_appendc_ex((dest), (c&0xFF00 ? c>>8 : '\0'), 0);
\
} while (0)
+#else
+#define smart_str_append2c(dest, c) do { \
+ smart_str_appendc_ex((dest), (c&0xFF00 ? c>>8 : '\0'), 0);
\
+ smart_str_appendc_ex((dest), (c&0xFF), 0); \
+} while (0)
+#endif
#define smart_str_free(s) \
smart_str_free_ex((s), 0)
Reproduce code:
---
% sapi/cli/php
ext/spl/tests/DirectoryIterator_getBasename_basic_test.php
Expected result:
getBasename_test
Actual result:
--
php goes into an infinite loop
--
Edit this bug report at http://bugs.php.net/?id=50189&edit=1
#50189 [Opn]: [PATCH] - unicode byte order difference between SPARC and x86
ID: 50189
User updated by: yoarvi at gmail dot com
Reported By: yoarvi at gmail dot com
Status: Open
Bug Type: *General Issues
Operating System: Solaris 10 (SPARC)
PHP Version: 6SVN-2009-11-16 (SVN)
New Comment:
Updated patch using WORDS_BIGENDIAN (suggested by christopher dot jones
at oracle dot com)
Index: ext/standard/php_smart_str.h
===
--- ext/standard/php_smart_str.h(revision 290471)
+++ ext/standard/php_smart_str.h(working copy)
@@ -86,10 +86,17 @@
smart_str_appendc_ex((dest), (c), 0)
/* appending of a single UTF-16 code unit (2 byte)*/
+#ifndef WORDS_BIGENDIAN
#define smart_str_append2c(dest, c) do { \
smart_str_appendc_ex((dest), (c&0xFF), 0); \
smart_str_appendc_ex((dest), (c&0xFF00 ? c>>8 : '\0'), 0);
\
} while (0)
+#else
+#define smart_str_append2c(dest, c) do { \
+ smart_str_appendc_ex((dest), (c&0xFF00 ? c>>8 : '\0'), 0);
\
+ smart_str_appendc_ex((dest), (c&0xFF), 0); \
+} while (0)
+#endif
#define smart_str_free(s) \
smart_str_free_ex((s), 0)
Previous Comments:
----------------
[2009-11-16 16:35:08] yoarvi at gmail dot com
ext/sqlite3/libsqlite/sqlite3.c uses
#if defined(i386) || defined(__i386__) || defined(_M_IX86)\
|| defined(__x86_64) ||
defined(__x86_64__)
Is that better?
[2009-11-16 13:07:50] tokul at users dot sourceforge dot net
If is not "#if (defined(i386) || defined(__i386__) || defined(_X86_))
" vs others.
It is little endian vs big endian. I suspect that code should not
assume that all other archs are big endian.
--------------------
[2009-11-16 12:20:44] yoarvi at gmail dot com
Description:
zspprintf() incorrectly represents strings/chars as unicode characters
on Solaris (SPARC).
There are byte ordering differences for unicode representations between
x86 and SPARC:
For example, the unicode representation (i've grouped them in sets of
2chars) of '/tmp' on x86 is
'/''\0' 't''\0' 'm''\0' 'p''\0'
and on SPARC it is
'\0''/' '\0''t' '\0''m' '\0''p'
http://marc.info/?l=php-internals&m=125811990106419&w=2 has some more
details.
the problem seems to be in the smart_str_append2c macro that
zspprintf()/xbuf_format_converter end up using.
The following patch fixes the problem:
Index: ext/standard/php_smart_str.h
===
--- ext/standard/php_smart_str.h(revision 290471)
+++ ext/standard/php_smart_str.h(working copy)
@@ -86,10 +86,17 @@
smart_str_appendc_ex((dest), (c), 0)
/* appending of a single UTF-16 code unit (2 byte)*/
+#if (defined(i386) || defined(__i386__) || defined(_X86_))
#define smart_str_append2c(dest, c) do { \
smart_str_appendc_ex((dest), (c&0xFF), 0); \
smart_str_appendc_ex((dest), (c&0xFF00 ? c>>8 : '\0'), 0);
\
} while (0)
+#else
+#define smart_str_append2c(dest, c) do { \
+ smart_str_appendc_ex((dest), (c&0xFF00 ? c>>8 : '\0'), 0);
\
+ smart_str_appendc_ex((dest), (c&0xFF), 0); \
+} while (0)
+#endif
#define smart_str_free(s) \
smart_str_free_ex((s), 0)
Reproduce code:
---
% sapi/cli/php
ext/spl/tests/DirectoryIterator_getBasename_basic_test.php
Expected result:
getBasename_test
Actual result:
--
php goes into an infinite loop
--
Edit this bug report at http://bugs.php.net/?id=50189&edit=1
#50226 [NEW]: [PATCH] - Insufficient memory allocation for unicode string
From: yoarvi at gmail dot com
Operating system: Solaris 5.10 (SPARC)
PHP version: 6SVN-2009-11-19 (SVN)
PHP Bug Type: *Unicode Issues
Bug description: [PATCH] - Insufficient memory allocation for unicode string
Description:
ext/standard/string.c:3460 allocates only 1 extra byte for the terminating
null
str.u = safe_emalloc(2, UBYTES(old_len), 1);
but then assigns a null at line 3482 using
*q.u = 0;
which writes 2 bytes.
The following patch fixes the problem:
Index: ext/standard/string.c
===
--- ext/standard/string.c (revision 290968)
+++ ext/standard/string.c (working copy)
@@ -3457,7 +3457,7 @@
if (type == IS_UNICODE) {
old_end.u = old.u + old_len;
- str.u = safe_emalloc(2, UBYTES(old_len), 1);
+ str.u = safe_emalloc(2, UBYTES(old_len), UBYTES(1));
for (p.u = old.u, q.u = str.u; p.u != old_end.u; p.u++) {
cp = *p.u;
Reproduce code:
---
./configure --enable-debug
% sapi/cli/php ext/standard/tests/strings/quotemeta_basic.php
Expected result:
*** Testing quotemeta() : basic functionality ***
unicode(20) "Hello how are you \?"
unicode(19) "\(100 \+ 50\) \* 10"
unicode(20) "\\\+\*\?\[\^\]\(\$\)"
Actual result:
--
*** Testing quotemeta() : basic functionality ***
unicode(20) "Hello how are you \?"
unicode(19) "\(100 \+ 50\) \* 10"
[Thu Nov 19 15:35:30 2009] Script:
'ext/standard/tests/strings/quotemeta_basic.php'
---
/home/arvi/php-trunk/ext/standard/string.c(3483) : Block 0x0969aed4
status:
Beginning: OK (allocated on
/home/arvi/php-trunk/ext/standard/string.c:3460, 41 bytes)
Start: OK
End: Overflown (magic=0x instead of 0x2C8088DB)
1 byte(s) overflown
---
unicode(20) ""
[Thu Nov 19 15:35:30 2009] Script:
'ext/standard/tests/strings/quotemeta_basic.php'
/home/arvi/php-trunk/ext/standard/string.c(3460) : Freeing 0x0969AED4 (41
bytes), script=ext/standard/tests/strings/quotemeta_basic.php
/home/arvi/php-trunk/Zend/zend_alloc.c(2446) : Actual location (location
was relayed)
=== Total 1 memory leaks detected ===
--
Edit bug report at http://bugs.php.net/?id=50226&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50226&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50226&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50226&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50226&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50226&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50226&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50226&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50226&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50226&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50226&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50226&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50226&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50226&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50226&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50226&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50226&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50226&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50226&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50226&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50226&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50226&r=mysqlcfg
#50237 [NEW]: [PATCH] - Enable correct behaviour when building PHP6 with Sun's compilers
From: yoarvi at gmail dot com Operating system: Solaris 5.10 (SPARC) PHP version: 6SVN-2009-11-20 (SVN) PHP Bug Type: *Compile Issues Bug description: [PATCH] - Enable correct behaviour when building PHP6 with Sun's compilers Description: The Sun Studio compilers don't seem to like it when a vararg is passed as a zstr union and then retrieved as a (UChar *). Specifying class_name.v instead of class_name to php_printf fixes the problem. This doesn't seem to be a problem on Ubuntu/gcc. Based on feedback (http://forums.sun.com/thread.jspa?threadID=5415962&tstart=00) from the Sun compiler folks, it seems that the following patch is necessary for PHP6 (trunk). http://bitbucket.org/arvi/arviq/src/tip/svn-zstr-varargs-patch.txt Reproduce code: --- http://marc.info/?l=php-internals&m=125802929326277&w=2 is the relevant mail thread on internals. Expected result: Tests such as tests/classes/__set__get_001.php should pass when executed using a PHP built with Sun Studio's compilers. Actual result: -- Lots of test failures on Solaris. -- Edit bug report at http://bugs.php.net/?id=50237&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50237&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50237&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50237&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50237&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50237&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50237&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50237&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50237&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50237&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50237&r=support Expected behavior: http://bugs.php.net/fix.php?id=50237&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50237&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50237&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50237&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50237&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50237&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50237&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50237&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50237&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50237&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50237&r=mysqlcfg
#50238 [NEW]: [PATCH] - Using #defines to improve the performance of the TSRMG macro
From: yoarvi at gmail dot com Operating system: Solaris 5.10 (SPARC) PHP version: 6SVN-2009-11-20 (SVN) PHP Bug Type: Performance problem Bug description: [PATCH] - Using #defines to improve the performance of the TSRMG macro Description: When compiled for multi-threaded (#ifdef ZTS ) operation, the various subsystems in PHP use dynamically allocated (ts_allocate_id) identifiers to index into the thread-local storage for each subsystem. These dynamically allocated ids are used by macros such as CG, EG, PG, AG. The TSRMG macro is defined as: #define TSRMG(id, type, element)(((type) (*((void ***) tsrm_ls))[TSRM_UNSHUFFLE_RSRC_ID(id)])->element) The PG macro is defined as: # define PG(v) TSRMG(core_globals_id, php_core_globals *, v) where core_globals_id is extern PHPAPI int core_globals_id; cc -E of PG(connection_status) = PHP_CONNECTION_ABORTED; translates to: (((php_core_globals *) (*((void ***) tsrm_ls))[((core_globals_id)-1)])->connection_status) = 1; and cc -S of the same code results in: .loc 1 108 0 movl%ebx, %eax sublcore_globals_id, %eax movl(%esi), %edx sall$2, %eax negl%eax movl(%edx,%eax), %eax movw$1, 144(%eax) I used fixed IDs instead of dynamically allocated ones and noticed a decent improvement in performance (few percentage points) when running a web-based ecommerce-site workload on SPARC CMT hardware. With my changes the PG macro is defined as: # define PG(v) TSRMG(CORE_GLOBALS_ID, php_core_globals *, v) #define CORE_GLOBALS_ID 10 and core_globals_id is extern PHPAPI const ts_rsrc_id core_globals_id; cc -E of the same line of code translates to: (((php_core_globals *) (*((void ***) tsrm_ls))[((10)-1)])->connection_status) = 1; cc -S (my version): .loc 1 108 0 movl(%eax), %eax movl36(%eax), %eax movw$1, 144(%eax) The relevant discussion can be found here: http://marc.info/?l=php-internals&m=125742200330841&w=2 Reproduce code: --- The following patch implements this and incorporates the feedback received on internals: http://bitbucket.org/arvi/arviq/src/tip/arvi-16-ts_allocate_reserved_id Expected result: Improved performance when PHP is compiled with support for multi-threading. -- Edit bug report at http://bugs.php.net/?id=50238&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50238&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50238&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50238&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50238&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50238&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50238&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50238&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50238&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50238&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50238&r=support Expected behavior: http://bugs.php.net/fix.php?id=50238&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50238&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50238&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50238&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50238&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50238&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50238&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50238&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50238&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50238&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50238&r=mysqlcfg
#50333 [NEW]: [PATCH] - Improving multi-threaded scalability by using emalloc/efree/estrdup
From: yoarvi at gmail dot com Operating system: Solaris 5.10 (SPARC) PHP version: 6SVN-2009-11-30 (SVN) PHP Bug Type: Performance problem Bug description: [PATCH] - Improving multi-threaded scalability by using emalloc/efree/estrdup Description: Using malloc/free in a multi-threaded process limits its scalability because of the process-wide lock inside malloc/free. The scalability of the PHP engine in a multi-threaded process can be improved by reducing the use of malloc/free/strdup and instead using emalloc/efree/estrdup wherever possible (at least in the main request processing code paths). The code paths in TSRM/tsrm_virtual_cwd.c are invoked quite frequently and they use malloc/free/strdup. I'd like to submit the following patches (based on the PHP6 source tree) for review that incorporate the use of emalloc/efree/estrdup in the virtual_cwd code paths. In order to use emalloc/efree I had to relocate tsrm_virtual_cwd.c from the TSRM directory to the Zend directory. I've split the change into 3 patches in order to make the changes easy to see Avoid name clash between global and local variable (http://bugs.php.net/bug.php?id=50101) http://bitbucket.org/arvi/arviq/src/tip/arvi-08-namespace Rename TSRM/tsrm_virtual_cwd.[ch] to Zend/zend_virtual_cwd.[ch] http://bitbucket.org/arvi/arviq/src/tip/arvi-08-virtual_cwd Replace malloc/free/strdup with emalloc/efree/estrdup http://bitbucket.org/arvi/arviq/src/tip/arvi-08-virtual_cwd-emalloc [http://marc.info/?l=php-internals&m=125846494007872&w=2] Expected result: Improved scalability on multi-threaded/multi-core systems. -- Edit bug report at http://bugs.php.net/?id=50333&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50333&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50333&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50333&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50333&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50333&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50333&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50333&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50333&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50333&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50333&r=support Expected behavior: http://bugs.php.net/fix.php?id=50333&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50333&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50333&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50333&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50333&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50333&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50333&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50333&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50333&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50333&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50333&r=mysqlcfg
#48609 [Com]: DateInterval::format() doesn't work
ID: 48609
Comment by: yoarvi at gmail dot com
Reported By: pierre dot inglebert at insa-rennes dot fr
Status: Open
Bug Type: Date/time related
Operating System: Debian Lenny
PHP Version: 5.3.0RC4
New Comment:
According to the documentation for DateInterval::format
(http://us.php.net/manual/en/dateinterval.format.php), the format
specifiers need to be prefixed with a %.
var_dump($diff->format('%H:%i:%s'));
var_dump($diff->format('%Y-%m-%d %H:%i:%s'));
produces the expected result.
Previous Comments:
[2009-06-19 17:19:19] pierre dot inglebert at insa-rennes dot fr
Description:
DateInterval::format method just returns the parameter given.
Reproduce code:
---
diff($date2,TRUE);
print_r($diff);
var_dump($diff->format('H:i:s'));
var_dump($diff->format('Y-m-d H:i:s'));
?>
Expected result:
DateInterval Object
(
[y] => 0
[m] => 0
[d] => 0
[h] => 0
[i] => 0
[s] => 40
[invert] => 0
[days] => 0
)
string(5) "00:00:40"
string(11) "-00-00 00:00:40"
Actual result:
--
DateInterval Object
(
[y] => 0
[m] => 0
[d] => 0
[h] => 0
[i] => 0
[s] => 40
[invert] => 0
[days] => 0
)
string(5) "H:i:s"
string(11) "Y-m-d H:i:s"
--
Edit this bug report at http://bugs.php.net/?id=48609&edit=1
#50436 [NEW]: [PATCH] - Improving multi-threaded performance by propagating TSRMLS_C
From: yoarvi at gmail dot com Operating system: Solaris 5.10 (SPARC) PHP version: 6SVN-2009-12-10 (SVN) PHP Bug Type: Performance problem Bug description: [PATCH] - Improving multi-threaded performance by propagating TSRMLS_C Description: When running a benchmarking workload on PHP that was configured with multi-threading support (--enable-maintainer-zts) I noticed that pthread_get_specific is invoked many times during the processing of a request. PHP code invokes TSRMLS_FETCH() (which ends up invoking ts_resource_ex) in a number of places. Caller/callee data from Sun Studio's collector/analyzer showed the following: Attr. Excl. Incl. Name User CPU User CPU User CPU sec. sec. sec. 178.105 185.460363.564 _emalloc 96.568 114.320210.888 _efree 27.96089.232343.901 _zval_ptr_dtor 19.544 6.685 26.228 php_body_write_wrapper 6.92536.806224.617 _zval_dtor_func 4.263 2.902 7.165 safe_free_zval_ptr_rel 4.16311.898 16.061 zend_get_parameters_ex 4.01314.690174.682 my_copy_zval 3.963 6.775 10.738 _erealloc 3.50212.399978.444 apc_copy_function_for_execution 2.732 4.143 9.647 do_inherit_method_check 2.59221.565225.137 _zval_copy_ctor_func 0.88122.095106.535 virtual_file_ex 0.600 1.961 6.855 list_entry_destructor 0.470 1.301 24.397 zend_file_handle_dtor 0.410 1.781 2.712 zend_function_dtor 0.270 0.350 0.620 convert_to_array 0.220 0.991 15.831 apc_search_paths 0.150 0.490 3.362 zend_register_resource 0.140 1.581 10.137 zend_alter_ini_entry 0.130 4.833 9023.272 php5_execute 0.110 0.500 3.502 zend_ini_long 0.070 0.530 0.600 _zend_bailout 0.050 0.320 4.513 zend_error 0.040 0.690 3.913 php_error_cb 0.040 0.560 2.852 zend_alter_ini_entry_ex 0.3.202584.369 php_request_shutdown 274.252 274.252357.910 *ts_resource_ex 83.65984.749 84.749 pthread_getspecific Propagating the value of TSRMLS_CC will avoid the overhead of having to invoke tsrm_tls_get/pthread_get_specific. The following patch (against trunk) does this: http://bitbucket.org/arvi/arviq/src/tip/svn-TSRM-patch.txt Reproduce code: --- http://marc.info/?l=php-internals&m=125958800305102&w=2 is the relevant email thread on the internals mailing list. Expected result: Improved multi-threaded performance. -- Edit bug report at http://bugs.php.net/?id=50436&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50436&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50436&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50436&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50436&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50436&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50436&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50436&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50436&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50436&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50436&r=support Expected behavior: http://bugs.php.net/fix.php?id=50436&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50436&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50436&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50436&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50436&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50436&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50436&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50436&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50436&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50436&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50436&r=mysqlcfg
#49904 [Com]: DateTime::modify('last day') returns last day of the month
ID: 49904
Comment by: yoarvi at gmail dot com
Reported By: kgrecki at gmail dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3, 6 (2009-10-19)
Assigned To: derick
New Comment:
The cause of the problem seems to be the optional 'of' in the regex
specification for the relative date operators 'first day of' and 'last
day of'.
After applying the following patch (and regenerating parse_date.c)
$dt->modify('first day'); is handled by the "relativetext" code block
in parse_date.re
and
$dt->modify('first day of'); is handled by the "firstdayof | lastdayof"
code block in parse_date.re
Index: ext/date/lib/parse_date.re
===
--- ext/date/lib/parse_date.re (revision 293574)
+++ ext/date/lib/parse_date.re (working copy)
@@ -931,8 +931,8 @@
isoweekday = year4 "-"? "W" weekofyear "-"? [0-7];
isoweek = year4 "-"? "W" weekofyear;
exif = year4 ":" monthlz ":" daylz " " hour24lz ":"
minutelz ":" secondlz;
-firstdayof = 'first day' ' of'?;
-lastdayof= 'last day' ' of'?;
+firstdayof = 'first day of';
+lastdayof= 'last day of'?;
backof = 'back of ' hour24 space? meridian?;
frontof = 'front of ' hour24 space? meridian?;
Previous Comments:
[2009-10-19 10:36:37] j...@php.net
Obvious regression.
[2009-10-16 16:45:18] kgrecki at gmail dot com
Description:
call to modify('last day') has different effect in PHP 5.3 than in 5.2
It used to return a previous day, now it seems to return last day of
the month,
according to
http://www.gnu.org/software/automake/manual/tar/General-date-syntax.html#SEC115
"last" means -1 so 5.2 seems to get it right
Reproduce code:
---
date_default_timezone_set('Europe/London');
$dt = new DateTime('today');
var_dump($dt->format('c'));
$dt->modify('last day');
var_dump($dt->format('c'));
$dt = new DateTime('01-04-2009');
var_dump($dt->format('c'));
$dt->modify('last day');
var_dump($dt->format('c'));
Expected result:
PHP 5.2.11 (cli) (built: Sep 18 2009 10:59:00)
string(25) "2009-10-16T00:00:00+01:00"
string(25) "2009-10-15T00:00:00+01:00"
string(25) "2009-04-01T00:00:00+01:00"
string(25) "2009-03-31T00:00:00+01:00"
Actual result:
--
PHP 5.3.0 (cli) (built: Jul 21 2009 17:02:21)
string(25) "2009-10-16T00:00:00+01:00"
string(25) "2009-10-31T00:00:00+00:00"
string(25) "2009-04-01T00:00:00+01:00"
string(25) "2009-04-30T00:00:00+01:00"
--
Edit this bug report at http://bugs.php.net/?id=49904&edit=1
#49904 [Com]: DateTime::modify('last day') returns last day of the month
ID: 49904
Comment by: yoarvi at gmail dot com
Reported By: kgrecki at gmail dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3, 6 (2009-10-19)
Assigned To: derick
New Comment:
The following patch is a test case for this bug:
Index: ext/date/tests/bug49904.phpt
===
--- ext/date/tests/bug49904.phpt(revision 0)
+++ ext/date/tests/bug49904.phpt(revision 0)
@@ -0,0 +1,27 @@
+--TEST--
+Bug #49904 (DateTime::modify('last day') returns last day of the
month)
+--FILE--
+format('c'));
+$dt->modify('last day');
+var_dump($dt->format('c'));
+$dt->modify('last day of');
+var_dump($dt->format('c'));
+
+$dt = new DateTime('18-01-2010');
+var_dump($dt->format('c'));
+$dt->modify('first day');
+var_dump($dt->format('c'));
+$dt->modify('first day of');
+var_dump($dt->format('c'));
+?>
+--EXPECT--
+string(25) "2010-01-18T00:00:00+05:30"
+string(25) "2010-01-17T00:00:00+05:30"
+string(25) "2010-01-31T00:00:00+05:30"
+string(25) "2010-01-18T00:00:00+05:30"
+string(25) "2010-01-19T00:00:00+05:30"
+string(25) "2010-01-01T00:00:00+05:30"
Previous Comments:
[2010-01-15 20:05:08] der...@php.net
Good point, but there is a reason why I made that 'of' bit optional,
I'll have to have a good look at why.
[2010-01-15 14:03:31] yoarvi at gmail dot com
The cause of the problem seems to be the optional 'of' in the regex
specification for the relative date operators 'first day of' and 'last
day of'.
After applying the following patch (and regenerating parse_date.c)
$dt->modify('first day'); is handled by the "relativetext" code block
in parse_date.re
and
$dt->modify('first day of'); is handled by the "firstdayof | lastdayof"
code block in parse_date.re
Index: ext/date/lib/parse_date.re
===
--- ext/date/lib/parse_date.re (revision 293574)
+++ ext/date/lib/parse_date.re (working copy)
@@ -931,8 +931,8 @@
isoweekday = year4 "-"? "W" weekofyear "-"? [0-7];
isoweek = year4 "-"? "W" weekofyear;
exif = year4 ":" monthlz ":" daylz " " hour24lz ":"
minutelz ":" secondlz;
-firstdayof = 'first day' ' of'?;
-lastdayof= 'last day' ' of'?;
+firstdayof = 'first day of';
+lastdayof= 'last day of'?;
backof = 'back of ' hour24 space? meridian?;
frontof = 'front of ' hour24 space? meridian?;
[2009-10-19 10:36:37] j...@php.net
Obvious regression.
[2009-10-16 16:45:18] kgrecki at gmail dot com
Description:
call to modify('last day') has different effect in PHP 5.3 than in 5.2
It used to return a previous day, now it seems to return last day of
the month,
according to
http://www.gnu.org/software/automake/manual/tar/General-date-syntax.html#SEC115
"last" means -1 so 5.2 seems to get it right
Reproduce code:
---
date_default_timezone_set('Europe/London');
$dt = new DateTime('today');
var_dump($dt->format('c'));
$dt->modify('last day');
var_dump($dt->format('c'));
$dt = new DateTime('01-04-2009');
var_dump($dt->format('c'));
$dt->modify('last day');
var_dump($dt->format('c'));
Expected result:
PHP 5.2.11 (cli) (built: Sep 18 2009 10:59:00)
string(25) "2009-10-16T00:00:00+01:00"
string(25) "2009-10-15T00:00:00+01:00"
string(25) "2009-04-01T00:00:00+01:00"
string(25) "2009-03-31T00:00:00+01:00"
Actual result:
--
PHP 5.3.0 (cli) (built: Jul 21 2009 17:02:21)
string(25) "2009-10-16T00:00:00+01:00"
string(25) "2009-10-31T00:00:00+00:00"
string(25) "2009-04-01T00:00:00+01:00"
string(25) "2009-04-30T00:00:00+01:00"
--
Edit this bug report at http://bugs.php.net/?id=49904&edit=1
#50475 [Com]: DateTime::setISODate followed by DateTime::setTime
ID: 50475
Comment by: yoarvi at gmail dot com
Reported By: nandobrt at gmail dot com
Status: Open
Bug Type: Date/time related
Operating System: Windows XP
PHP Version: 5.3SVN-2009-12-15 (snap)
New Comment:
date_isodate_set should reset the have_relative flag once it has
updated the date/time value.
The following patch (5.3 svn tree) includes a fix and a test case for
this bug:
Index: ext/date/php_date.c
===
--- ext/date/php_date.c (revision 293574)
+++ ext/date/php_date.c (working copy)
@@ -3033,6 +3033,8 @@
timelib_update_ts(dateobj->time, NULL);
+ dateobj->time->have_relative = 0;
+
RETURN_ZVAL(object, 1, 0);
}
/* }}} */
Index: ext/date/tests/bug50475.phpt
===
--- ext/date/tests/bug50475.phpt(revision 0)
+++ ext/date/tests/bug50475.phpt(revision 0)
@@ -0,0 +1,16 @@
+--TEST--
+Bug #50475 (DateTime::setISODate followed by DateTime::setTime)
+--FILE--
+setISODate(2009, 6, 1);
+echo $date->format('Y-m-d H:i:s') . "\n";
+$date->setTime(8, 0);
+echo $date->format('Y-m-d H:i:s') . "\n";
+?>
+--EXPECT--
+2009-02-02 00:00:00
+2009-02-02 08:00:00
+
Previous Comments:
[2009-12-15 03:23:53] nandobrt at gmail dot com
Description:
Calling setTime on a DateTime object after having called setISODate
will change its date.
Reproduce code:
---
$date = new DateTime();
$date->setISODate(2009, 6);
echo $date->format('Y-m-d H:i:s') . "";
$date->setTime(8, 0);
echo $date->format('Y-m-d H:i:s');
Expected result:
2009-02-02 01:11:15
2009-02-02 08:00:00
Actual result:
--
2009-02-02 01:11:15
2009-03-06 08:00:00
--
Edit this bug report at http://bugs.php.net/?id=50475&edit=1
#49059 [Com]: DateTime::diff() repeats previous sub() operation
ID: 49059
Comment by: yoarvi at gmail dot com
Reported By: lopez dot fernandez dot jorge at gmail dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Ubuntu 9.04
PHP Version: 5.3.0
Assigned To: derick
New Comment:
date_sub in php_date.c doesn't reset dateobj->time->have_relative.
The following patch (against 5.3 SVN) includes a fix and a test case:
Index: ext/date/php_date.c
===
--- ext/date/php_date.c (revision 293574)
+++ ext/date/php_date.c (working copy)
@@ -2861,6 +2861,8 @@
timelib_update_ts(dateobj->time, NULL);
timelib_update_from_sse(dateobj->time);
+ dateobj->time->have_relative = 0;
+
RETURN_ZVAL(object, 1, 0);
}
/* }}} */
Index: ext/date/tests/bug49059.phpt
===
--- ext/date/tests/bug49059.phpt(revision 0)
+++ ext/date/tests/bug49059.phpt(revision 0)
@@ -0,0 +1,35 @@
+--TEST--
+Bug #49059 (DateTime::diff() repeats previous sub() operation)
+--FILE--
+format("Y-m-d") . "\n";
+print "\$date2 at init: " . $date2->format("Y-m-d") . "\n";
+$diff = $date1->diff($date2);
+print "\$date1 after first diff: " . $date1->format("Y-m-d") . "\n";
+print "\$diff->days after first diff: " . $diff->days . "\n";
+$date1 = $date1->sub(new DateInterval("P2D"));
+print "\$date1 after sub: " . $date1->format("Y-m-d") . "\n";
+$diff = $date1->diff($date2);
+print "\$date1 after second diff (called at \$date1): " .
+$date1->format("Y-m-d") . "\n";
+print "\$diff->days after second diff: " . $diff->days . "\n";
+$diff = $date2->diff($date1);
+print "\$date1 after third diff (called at \$date2): " .
+$date1->format("Y-m-d") . "\n";
+print "\$diff->days after third diff: " . $diff->days . "\n";
+?>
+--EXPECT--
+$date1 at init: 2009-03-27
+$date2 at init: 2009-03-01
+$date1 after first diff: 2009-03-27
+$diff->days after first diff: 26
+$date1 after sub: 2009-03-25
+$date1 after second diff (called at $date1): 2009-03-25
+$diff->days after second diff: 24
+$date1 after third diff (called at $date2): 2009-03-25
+$diff->days after third diff: 24
+
Previous Comments:
[2009-07-26 00:12:34] lopez dot fernandez dot jorge at gmail dot com
Description:
When you call the 'diff' function onto or from a DateTime object that
did a 'sub' operation before, it will substract again the same amount of
time from the DateTime object before calculating the difference, so
neither the result nor the DateTime object will have the correct values.
Reproduce code:
---
format("Y-m-d") . "\n";
print "\$date2 at init: " . $date2->format("Y-m-d") . "\n";
$diff = $date1->diff($date2);
print "\$date1 after first diff: " . $date1->format("Y-m-d") . "\n";
print "\$diff->days after first diff: " . $diff->days . "\n";
$date1 = $date1->sub(new DateInterval("P2D"));
print "\$date1 after sub: " . $date1->format("Y-m-d") . "\n";
$diff = $date1->diff($date2);
print "\$date1 after second diff (called at \$date1): " .
$date1->format("Y-m-d") . "\n";
print "\$diff->days after second diff: " . $diff->days . "\n";
$diff = $date2->diff($date1);
print "\$date1 after third diff (called at \$date2): " .
$date1->format("Y-m-d") . "\n";
print "\$diff->days after third diff: " . $diff->days . "\n";
?>
Expected result:
$date1 at init: 2009-03-27
$date2 at init: 2009-03-01
$date1 after first diff: 2009-03-27
$diff->days after first diff: 26
$date1 after sub: 2009-03-25
$date1 after second diff (called at $date1): 2009-03-25
$diff->days after second diff: 24
$date1 after third diff (called at $date2): 2009-03-25
$diff->days after third diff: 24
Actual result:
--
$date1 at init: 2009-03-27
$date2 at init: 2009-03-01
$date1 after first diff: 2009-03-27
$diff->days after first diff: 26
$date1 after sub: 2009-03-25
$date1 after second diff (called at $date1): 2009-03-23
$diff->days after second diff: 22
$date1 after third diff (called at $date2): 2009-03-21
$diff->days after third diff: 20
--
Edit this bug report at http://bugs.php.net/?id=49059&edit=1
#46111 [Com]: strtotime() returns false for some valid timezones
ID: 46111
Comment by: yoarvi at gmail dot com
Reported By: jason at eventshop dot com dot au
Status: Verified
Bug Type: Date/time related
Operating System: *
PHP Version: 5.*, 6CVS (2009-05-10)
New Comment:
The failures in PHP 5.3 are the following:
Africa/Dar_es_Salaam
Africa/Porto-Novo
America/Blanc-Sablon
America/Port-au-Prince
America/Port_of_Spain
Antarctica/DumontDUrville
Antarctica/McMurdo
The regex for tz in parse_date.re doesn't account for hyphens, or for
lower-case following an _ or for consecutive upper case letters.
Applying the following patch and regenerating parse_date.c fixes the
problem:
Index: ext/date/lib/parse_date.re
===
--- ext/date/lib/parse_date.re (revision 293574)
+++ ext/date/lib/parse_date.re (working copy)
@@ -854,7 +854,7 @@
second = minute | "60";
secondlz = minutelz | "60";
meridian = ([AaPp] "."? [Mm] "."?) [\000\t ];
-tz = "("? [A-Za-z]{1,6} ")"? | [A-Z][a-z]+([_/][A-Z][a-z]+)+;
+tz = "("? [A-Za-z]{1,6} ")"? | [A-Z][a-z]+([_/-][A-Za-z]+)+;
tzcorrection = "GMT"? [+-] hour24 ":"? minute?;
daysuf = "st" | "nd" | "rd" | "th";
Previous Comments:
[2009-05-10 21:19:37] j...@php.net
The list is a bit shorter with PHP_5_3 than with PHP_5_2..some
progress?
:)
[2008-09-18 06:01:34] jason at eventshop dot com dot au
Description:
When converting a date/time/timezone string using strtotime(), it
returns false for several of the supposedly valid timezones, such as
"Adelaide/ACT", "Israel", "US/Arizona", etc.
All other timezones work correctly.
Reproduce code:
---
$timezones = timezone_identifiers_list();
foreach ($timezones as $zone) {
$date_string = "2008-01-01 13:00:00 " . $zone;
if (!strtotime($date_string)) {
echo "" . $zone;
}
}
Expected result:
No result should be displayed.
Actual result:
--
Africa/Dar_es_Salaam
Africa/Porto-Novo
America/Argentina/ComodRivadavia
America/Blanc-Sablon
... etc ...
US/Pacific
US/Pacific-New
US/Samoa
W-SU
Zulu
--
Edit this bug report at http://bugs.php.net/?id=46111&edit=1
#48902 [Com]: datetimezone uses calcutta or kolkata
ID: 48902
Comment by: yoarvi at gmail dot com
Reported By: husen at fiare dot fi
Status: Assigned
Bug Type: Date/time related
Operating System: kubuntu
PHP Version: 5.3.0
Assigned To: derick
New Comment:
Kolkata is the new/official name of Calcutta. The following patch
(against 5.3 SVN) fixes this:
Index: ext/date/lib/timezonemap.h
===
--- ext/date/lib/timezonemap.h (revision 293574)
+++ ext/date/lib/timezonemap.h (working copy)
@@ -292,7 +292,7 @@
{ "bst", 1, 3600, "GB-Eire" },
{ "btt", 0, 21600, "Asia/Thimbu" },
{ "btt", 0, 21600, "Asia/Thimphu" },
- { "burt", 0, 23400, "Asia/Calcutta" },
+ { "burt", 0, 23400, "Asia/Kolkata" },
{ "burt", 0, 23400, "Asia/Dacca"},
{ "burt", 0, 23400, "Asia/Dhaka"},
{ "burt", 0, 23400, "Asia/Rangoon" },
@@ -1003,7 +1003,7 @@
{ "ist", 0, 7200, "Asia/Jerusalem"},
{ "ist", 0, -3600, "Atlantic/Reykjavik"},
{ "ist", 0, -3600, "Iceland" },
- { "ist", 0, 19800, "Asia/Calcutta" },
+ { "ist", 0, 19800, "Asia/Kolkata" },
{ "ist", 0, 19800, "Asia/Colombo" },
{ "ist", 0, 19800, "Asia/Dacca"},
{ "ist", 0, 19800, "Asia/Dhaka"},
@@ -1013,7 +1013,7 @@
{ "ist", 0, 19800, "Asia/Thimphu" },
{ "ist", 1, 2079, "Eire" },
{ "ist", 1, 2079, "Europe/Dublin" },
- { "ist", 1, 23400, "Asia/Calcutta" },
+ { "ist", 1, 23400, "Asia/Kolkata" },
{ "ist", 1, 23400, "Asia/Colombo" },
{ "ist", 1, 23400, "Asia/Karachi" },
{ "ist", 0, 3600, "Eire" },
Index: ext/date/lib/fallbackmap.h
===
--- ext/date/lib/fallbackmap.h (revision 293574)
+++ ext/date/lib/fallbackmap.h (working copy)
@@ -26,7 +26,7 @@
{ "msd", 1,4, "Europe/Moscow" },
{ "gst", 0,4, "Asia/Dubai" },
{ "pkt", 0,5, "Asia/Karachi" },
- { "ist", 0, 5.5, "Asia/Calcutta" },
+ { "ist", 0, 5.5, "Asia/Kolkata" },
{ "npt", 0, 5.75, "Asia/Katmandu" },
{ "yekt", 1,6, "Asia/Yekaterinburg" },
{ "novst", 1,7, "Asia/Novosibirsk" },
Previous Comments:
[2009-07-13 08:31:02] der...@php.net
They are aliases of each other. Kolkata was only very recently added as
a preferred version of Calcutta. It seems that our "precedence table"
hasn't been updated.
[2009-07-13 08:26:31] husen at fiare dot fi
Description:
DateTimeZone::listIdentifiers returns [236] => Asia/Kolkata while
DateTimeZone::listAbbreviations() returns [timezone_id] =>
Asia/Calcutta
I mean former is using "Kolkata" while later is "Calcutta". It is not
supposed to be either one of the Kolkata or Calcutta for both of the
functions?
Regards
--
Edit this bug report at http://bugs.php.net/?id=48902&edit=1
#46111 [Com]: strtotime() returns false for some valid timezones
ID: 46111
Comment by: yoarvi at gmail dot com
Reported By: jason at eventshop dot com dot au
Status: Verified
Bug Type: Date/time related
Operating System: *
PHP Version: 5.*, 6CVS (2009-05-10)
New Comment:
Test case:
Index: ext/date/tests/bug46111.phpt
===
--- ext/date/tests/bug46111.phpt(revision 0)
+++ ext/date/tests/bug46111.phpt(revision 0)
@@ -0,0 +1,23 @@
+--TEST--
+Bug #46111 (strtotime() returns false for some valid timezones)
+--FILE--
+
+--EXPECT--
+[strtotime(timezone) == false - Begin List]
+[strtotime(timezone) == false - End List]
+
Previous Comments:
[2010-01-21 14:00:59] yoarvi at gmail dot com
The failures in PHP 5.3 are the following:
Africa/Dar_es_Salaam
Africa/Porto-Novo
America/Blanc-Sablon
America/Port-au-Prince
America/Port_of_Spain
Antarctica/DumontDUrville
Antarctica/McMurdo
The regex for tz in parse_date.re doesn't account for hyphens, or for
lower-case following an _ or for consecutive upper case letters.
Applying the following patch and regenerating parse_date.c fixes the
problem:
Index: ext/date/lib/parse_date.re
===
--- ext/date/lib/parse_date.re (revision 293574)
+++ ext/date/lib/parse_date.re (working copy)
@@ -854,7 +854,7 @@
second = minute | "60";
secondlz = minutelz | "60";
meridian = ([AaPp] "."? [Mm] "."?) [\000\t ];
-tz = "("? [A-Za-z]{1,6} ")"? | [A-Z][a-z]+([_/][A-Z][a-z]+)+;
+tz = "("? [A-Za-z]{1,6} ")"? | [A-Z][a-z]+([_/-][A-Za-z]+)+;
tzcorrection = "GMT"? [+-] hour24 ":"? minute?;
daysuf = "st" | "nd" | "rd" | "th";
[2009-05-10 21:19:37] j...@php.net
The list is a bit shorter with PHP_5_3 than with PHP_5_2..some
progress?
:)
[2008-09-18 06:01:34] jason at eventshop dot com dot au
Description:
When converting a date/time/timezone string using strtotime(), it
returns false for several of the supposedly valid timezones, such as
"Adelaide/ACT", "Israel", "US/Arizona", etc.
All other timezones work correctly.
Reproduce code:
---
$timezones = timezone_identifiers_list();
foreach ($timezones as $zone) {
$date_string = "2008-01-01 13:00:00 " . $zone;
if (!strtotime($date_string)) {
echo "" . $zone;
}
}
Expected result:
No result should be displayed.
Actual result:
--
Africa/Dar_es_Salaam
Africa/Porto-Novo
America/Argentina/ComodRivadavia
America/Blanc-Sablon
... etc ...
US/Pacific
US/Pacific-New
US/Samoa
W-SU
Zulu
--
Edit this bug report at http://bugs.php.net/?id=46111&edit=1
#50559 [Com]: Clone is not implemented for DateInterval and DatePeriod
ID: 50559
Comment by: yoarvi at gmail dot com
Reported By: sr at emini dot dk
Status: Assigned
Bug Type: Date/time related
Operating System: Fedora 10
PHP Version: 5.3.1
Assigned To: derick
New Comment:
The following patch implements the logic to clone DatePeriod and
DateInterval objects and also includes a test case:
Index: ext/date/php_date.c
===
--- ext/date/php_date.c (revision 293574)
+++ ext/date/php_date.c (working copy)
@@ -2213,7 +2213,9 @@
zend_objects_clone_members(&new_obj->std, new_ov, &old_obj->std,
Z_OBJ_HANDLE_P(this_ptr) TSRMLS_CC);
- /** FIX ME ADD CLONE STUFF **/
+ new_obj->diff = timelib_rel_time_clone(old_obj->diff);
+ new_obj->initialized = 1;
+
return new_ov;
}
@@ -2283,7 +2285,27 @@
zend_objects_clone_members(&new_obj->std, new_ov, &old_obj->std,
Z_OBJ_HANDLE_P(this_ptr) TSRMLS_CC);
- /** FIX ME ADD CLONE STUFF **/
+ new_obj->start = timelib_time_ctor();
+ *new_obj->start = *old_obj->start;
+ if (old_obj->start->tz_abbr) {
+ new_obj->start->tz_abbr = strdup(old_obj->start->tz_abbr);
+ }
+ if (old_obj->start->tz_info) {
+ new_obj->start->tz_info = old_obj->start->tz_info;
+ }
+ new_obj->end = timelib_time_ctor();
+ *new_obj->end = *old_obj->end;
+ if (old_obj->end->tz_abbr) {
+ new_obj->end->tz_abbr = strdup(old_obj->end->tz_abbr);
+ }
+ if (old_obj->end->tz_info) {
+ new_obj->end->tz_info = old_obj->end->tz_info;
+ }
+ new_obj->interval = timelib_rel_time_clone(old_obj->interval);
+ new_obj->recurrences = old_obj->recurrences;
+ new_obj->include_start_date = old_obj->include_start_date;
+ new_obj->initialized = 1;
+
return new_ov;
}
Index: ext/date/tests/bug50559.phpt
===
--- ext/date/tests/bug50559.phpt(revision 0)
+++ ext/date/tests/bug50559.phpt(revision 0)
@@ -0,0 +1,131 @@
+--TEST--
+Bug #50559 (Clone is not implemented for DateInterval and DatePeriod)
+--FILE--
+format("l Y-m-d H:i:s\n");
+}
+
+echo "\n";
+echo "DatePeriod (clone)\n";
+foreach ($datePeriod2 as $p) {
+ echo $p->format("l Y-m-d H:i:s\n");
+}
+echo "\n";
+?>
+--EXPECT--
+
+DateInterval (original)
+object(DateInterval)#1 (8) {
+ ["y"]=>
+ int(0)
+ ["m"]=>
+ int(0)
+ ["d"]=>
+ int(1)
+ ["h"]=>
+ int(0)
+ ["i"]=>
+ int(0)
+ ["s"]=>
+ int(0)
+ ["invert"]=>
+ int(0)
+ ["days"]=>
+ int(0)
+}
+
+DateInterval (clone)
+object(DateInterval)#2 (8) {
+ ["y"]=>
+ int(0)
+ ["m"]=>
+ int(0)
+ ["d"]=>
+ int(1)
+ ["h"]=>
+ int(0)
+ ["i"]=>
+ int(0)
+ ["s"]=>
+ int(0)
+ ["invert"]=>
+ int(0)
+ ["days"]=>
+ int(0)
+}
+
+DatePeriod (original)
+Thursday 2008-01-31 00:00:00
+Thursday 2008-02-28 00:00:00
+Thursday 2008-03-27 00:00:00
+Thursday 2008-04-24 00:00:00
+Thursday 2008-05-29 00:00:00
+Thursday 2008-06-26 00:00:00
+Thursday 2008-07-31 00:00:00
+Thursday 2008-08-28 00:00:00
+Thursday 2008-09-25 00:00:00
+Thursday 2008-10-30 00:00:00
+Thursday 2008-11-27 00:00:00
+Thursday 2008-12-25 00:00:00
+Thursday 2009-01-29 00:00:00
+Thursday 2009-02-26 00:00:00
+Thursday 2009-03-26 00:00:00
+Thursday 2009-04-30 00:00:00
+Thursday 2009-05-28 00:00:00
+Thursday 2009-06-25 00:00:00
+Thursday 2009-07-30 00:00:00
+Thursday 2009-08-27 00:00:00
+Thursday 2009-09-24 00:00:00
+Thursday 2009-10-29 00:00:00
+Thursday 2009-11-26 00:00:00
+Thursday 2009-12-31 00:00:00
+
+DatePeriod (clone)
+Thursday 2008-01-31 00:00:00
+Thursday 2008-02-28 00:00:00
+Thursday 2008-03-27 00:00:00
+Thursday 2008-04-24 00:00:00
+Thursday 2008-05-29 00:00:00
+Thursday 2008-06-26 00:00:00
+Thursday 2008-07-31 00:00:00
+Thursday 2008-08-28 00:00:00
+Thursday 2008-09-25 00:00:00
+Thursday 2008-10-30 00:00:00
+Thursday 2008-11-27 00:00:00
+Thursday 2008-12-25 00:00:00
+Thursday 2009-01-29 00:00:00
+Thursday 2009-02-26 00:00:00
+Thursday 2009-03-26 00:00:00
+Thursday 2009-04-30 00:00:00
+Thursday 2009-05-28 00:00:00
+Thursday 2009-06-25 00:00:00
+Thursday 2009-07-30 00:00:00
+Thursday 2009-08-27 00:00:00
+Thursday 2009-09-24 00:00:00
+Thursday 2009-10-29 00:00:00
+Thursday 2009-11-26 00:00:00
+Thursday 2009-12-31 00:00:00
+==
Bug #50916 [Com]: DateTime::sub repeats each time getTimestamp is called
Edit report at http://bugs.php.net/bug.php?id=50916&edit=1
ID: 50916
Comment by: yoarvi at gmail dot com
Reported by: charlesb at itsmystuff dot com
Summary: DateTime::sub repeats each time getTimestamp is called
Status: Open
Type: Bug
Package: Date/time related
Operating System: Windows Server 2003 SP2
PHP Version: 5.3.1
New Comment:
The fix for http://bugs.php.net/bug.php?id=49059 fixes this problem as
well. I think this bug can be closed as a duplicate of 49059.
Previous Comments:
[2010-03-02 23:00:01] v-ryanbi at microsoft dot com
I've attached a patch that is tested on Windows, although the code that
needs to be changed appears to be universal. The patch also includes a
.phpt that compares the resulting timestamps.
The fix for this is a bit disconcerting for me, but as I'm not entirely
familiar with the codebase, I didn't want to muck things up too much.
Shouldn't the c function do_adjust_relative() in tm2unixtime.c be the
one to clear the flags it uses after it applies changes? If we're
clearing the flags in the calling functions, we're bound to miss more
stuff like this one.
[2010-02-20 10:28:40] pontus dot alexander at gmail dot com
This bug is confirmed to still be alive in snapshot "5.3-201002200930"
compiled on Debian Linux.
Reproduction code:
$Time = new \DateTime('NOW');
$Month = new \DateInterval('P1Y');
var_dump($Time);
// Correctly subtracted
$Time->sub($Month);
var_dump($Time);
// Wrongly subtracted
$Time->getTimestamp();
var_dump($Time);
[2010-02-02 18:04:23] charlesb at itsmystuff dot com
Description:
Each time DateTime::getTimestamp is called, a previously called
DateTime::sub value is applied. This does not occur with DateTime::add.
Reproduce code:
---
$work_time = new DateTime("2010-01-30 12:00:00");
$work_time->sub(new DateInterval("P7D"));
$window_start = $work_time->getTimestamp();
echo date("Y-m-d H:i:s", $window_start) . "";
$window_start = $work_time->getTimestamp();
echo date("Y-m-d H:i:s", $window_start) . "";
Expected result:
2010-01-23 12:00:00
2010-01-23 12:00:00
Actual result:
--
2010-01-16 12:00:00
2010-01-09 12:00:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=50916&edit=1
