#50663 [Bgs]: exec and shell_exec don't works with msginit
ID: 50663 Updated by: ras...@php.net Reported By: samuel dot roze at gmail dot com Status: Bogus Bug Type: Program Execution Operating System: Debian 5 PHP Version: 5.3.1 New Comment: Yes, but from the command line stderr is printed alongside stdout. exec will only give you whatever is sent to stdout. Try redirecting stderr. But again, this is not a PHP bug. And this is not a support forum. Previous Comments: [2010-01-05 06:11:23] samuel dot roze at gmail dot com Well, I said that it works on cli... Actually, the "file.po" file is created, BUT the result of $exec is still empty instead of be the expected string! The this string is directly printed on my command line, and isn't returned to PHP. [2010-01-04 23:18:48] ras...@php.net Sorry, but these types of issues are never PHP-related. You just proved it yourself that when you ran PHP in a cli environment, it worked fine. But in the Apache environment it didn't. Therefore it has to do with something in your Apache environment. Like environment variables, LOCALE, or maybe even a requirement for a controlling tty, or something along those lines. Regardless, it has nothing to do with PHP. strace the working one and compare it to the strace of the non- working one and figure out what is going on. [2010-01-04 22:39:36] samuel dot roze at gmail dot com Notice: This PHP test work when using the "php file.php" command but no on Apache. With the command, the message "/home/samuel/Développement/workspaces/PHP/GetTextEdit/tests/php/file.po a été créé." is printed on the shell, nothing is sent to PHP. [2010-01-04 22:23:19] samuel dot roze at gmail dot com Description: The function exec or the shell_exec function are not working with the msginit (gettext) program. Reproduce code: --- Create an empty "/home/user/file.pot" file. Expected result: string(X) "/home/d-sites/myonlinessh/includes/locales/ps_AK/messages a été créé." and that the file.po file was created. Actual result: -- string(0) "" and the file.po doesn't exists. Note: there's any error and the same command, with the www-data user (used by Apache) works in my shell! -- Edit this bug report at http://bugs.php.net/?id=50663&edit=1
#50663 [Bgs]: exec and shell_exec don't works with msginit
ID: 50663 User updated by: samuel dot roze at gmail dot com Reported By: samuel dot roze at gmail dot com Status: Bogus Bug Type: Program Execution Operating System: Debian 5 PHP Version: 5.3.1 New Comment: Well, I said that it works on cli... Actually, the "file.po" file is created, BUT the result of $exec is still empty instead of be the expected string! The this string is directly printed on my command line, and isn't returned to PHP. Previous Comments: [2010-01-04 23:18:48] ras...@php.net Sorry, but these types of issues are never PHP-related. You just proved it yourself that when you ran PHP in a cli environment, it worked fine. But in the Apache environment it didn't. Therefore it has to do with something in your Apache environment. Like environment variables, LOCALE, or maybe even a requirement for a controlling tty, or something along those lines. Regardless, it has nothing to do with PHP. strace the working one and compare it to the strace of the non- working one and figure out what is going on. [2010-01-04 22:39:36] samuel dot roze at gmail dot com Notice: This PHP test work when using the "php file.php" command but no on Apache. With the command, the message "/home/samuel/Développement/workspaces/PHP/GetTextEdit/tests/php/file.po a été créé." is printed on the shell, nothing is sent to PHP. [2010-01-04 22:23:19] samuel dot roze at gmail dot com Description: The function exec or the shell_exec function are not working with the msginit (gettext) program. Reproduce code: --- Create an empty "/home/user/file.pot" file. Expected result: string(X) "/home/d-sites/myonlinessh/includes/locales/ps_AK/messages a été créé." and that the file.po file was created. Actual result: -- string(0) "" and the file.po doesn't exists. Note: there's any error and the same command, with the www-data user (used by Apache) works in my shell! -- Edit this bug report at http://bugs.php.net/?id=50663&edit=1
#50514 [Bgs]: failure while running make test
ID: 50514 User updated by: pushpender007 at gmail dot com Reported By: pushpender007 at gmail dot com Status: Bogus Bug Type: Compile Failure Operating System: SUSE Enterprise Server s390x PHP Version: 5.2SVN-2009-12-18 (snap) New Comment: Hello ..Can you please confirm should I continue my installation or what else solution we have for the error in make test? Thanks Previous Comments: [2009-12-22 15:16:21] pushpender007 at gmail dot com This is new result file with version 5.2.12. http://pushpender007.byethost6.com/php_test_results_20091222_1455.txt As you saying you are facing these errors too.Should I install as it is ,ignoring error? [2009-12-22 13:39:25] j...@php.net Well that explained a lot. First of all: You're testing 5.2.3? We're at 5.2.12 already, upgrade.. And next issue: Any tests failing fail also for me so nothing unexpected, we know about it, move along, nothing to see here.. [2009-12-22 10:42:28] pushpender007 at gmail dot com I have mailed the test report to the qa-repo...@lists.php.net and also uploaded to http://pushpender007.byethost6.com/php_test_results_20091222_0527.txt .Please check them.thanks [2009-12-22 10:15:43] pushpender007 at gmail dot com Can you please tell the file name of that result file? thanks [2009-12-22 09:00:22] j...@php.net Those diffs alone are meaningless. Use the 'save results' option in the end instead and provide that. Or rather send it straight away to the mailing list like suggested. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50514 -- Edit this bug report at http://bugs.php.net/?id=50514&edit=1
#47281 [Asn->Ana]: $php_errormsg is limited in size of characters
ID: 47281 Updated by: s...@php.net Reported By: jeffersongranatto at mannesoft dot com dot br -Status: Assigned +Status: Analyzed Bug Type: OCI8 related Operating System: Linux PHP Version: 5.3.1 Assigned To: sixd New Comment: Confirmed. Previous Comments: [2009-12-29 14:47:08] johan...@php.net Chris, please check this. [2009-12-27 17:03:05] jeffersongranatto at mannesoft dot com dot br Solution: In ext/oci8/oci8.c, change the value of the constant PHP_OCI_ERRBUF_LEN to 1024. It's the biggest message that Oracle can return. [2009-02-02 18:08:54] jeffersongranatto at mannesoft dot com dot br Description: Sometimes, I need to show a big error message on a trigger of Oracle. Oracle supports this type of situation, but $php_errormsg does not display more than 500 characters. Reproduce code: --- create procedure sp_test as begin raise_application_error(-2, 'more than 500 characters'); end; $stmt = ociparse($conn, 'begin sp_test; end;'); ociexecute($stmt, OCI_DEFAULT); echo $php_errormsg; Expected result: The full message. Actual result: -- The message truncated to 500 characters. -- Edit this bug report at http://bugs.php.net/?id=47281&edit=1
#48590 [Ver->Csd]: SOAP Client (redirect loop)
ID: 48590
Updated by: srina...@php.net
Reported By: erik at datahack dot se
-Status: Verified
+Status: Closed
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5.3.0RC3
-Assigned To:
+Assigned To: srinatar
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
here is a patch that should address this issue
Index: ext/soap/php_http.c
===
--- ext/soap/php_http.c (revision 293128)
+++ ext/soap/php_http.c (working copy)
@@ -207,6 +207,7 @@
int http_1_1;
int http_status;
int content_type_xml = 0;
+ long redirect_max = 20;
char *content_encoding;
char *http_msg = NULL;
zend_bool old_allow_url_fopen;
@@ -283,6 +284,14 @@
context = php_stream_context_from_zval(*tmp, 0);
}
+ if (context &&
+ php_stream_context_get_option(context, "http",
"max_redirects", &tmp) == SUCCESS) {
+ if (Z_TYPE_PP(tmp) != IS_STRING ||
!is_numeric_string(Z_STRVAL_PP(tmp), Z_STRLEN_PP(tmp), &redirect_max,
NULL, 1)) {
+ if (Z_TYPE_PP(tmp) == IS_LONG)
+ redirect_max = Z_LVAL_PP(tmp);
+ }
+ }
+
try_again:
if (phpurl == NULL || phpurl->host == NULL) {
if (phpurl != NULL) {php_url_free(phpurl);}
@@ -1012,6 +1021,12 @@
}
phpurl = new_url;
+ if (--redirect_max < 1) {
+
smart_str_free(&soap_headers_z);
+ add_soap_fault(this_ptr,
"HTTP", "Redirection limit reached, aborting", NULL, NULL TSRMLS_CC);
+ return FALSE;
+ }
+
goto try_again;
}
}
Previous Comments:
[2009-09-10 15:08:04] sjo...@php.net
Could reproduce with latest 5.3.
[2009-06-17 21:11:45] erik at datahack dot se
The sample code has an extra comma after the "'stream_context' =>
$context,".
[2009-06-17 21:05:23] erik at datahack dot se
Description:
A SOAPClient can be stuck in a redirect loop (and in some cases crash).
Other PHP functions have solved this by a default redirection limit of
20 redirects (maybe a php.ini setting) or a custom value of a stream
context -> http -> max_redirects.
I provide two examples, one where PHP crashes after ~200 requests and
one where it just loops forever.
Reproduce code:
---
redirection-loop.php:
client code (crashes):
array('max_redirects' => 3))
);
$soap = new SOAPClient(NULL,
array(
'uri' => 'foo',
'location' => 'http://example.com/redirection-loop.php',
'stream_context' => $context,
)
);
$soap->test();
?>
client code (never finishes):
'foo',
'location' => 'http://example.com/redirection-loop.php'
)
);
$soap->test();
?>
Expected result:
I expect it to have a default limit of 20 but also respect the
max_requests value in the stream context. If the limit is reached I
would expect a SOAPFault with a similar error description as below.
When requesting the same file (redirection-loop.php) with
file_get_contents() you get a warning and a empty result is returned.
Warning: file_get_contents(http://example.com/redirection-loop.php):
failed to open stream: Redirection limit reached, aborting in Command
line code on line 1
Actual result:
--
This is what happens if you specify a stream_context and tries to make
it respect the max_requests (which is does not)...
(gdb) bt
#0 0x082e2c9e in php_stream_context_get_option (context=0xa2eb5b4,
wrappername=0x85eb353 "socket", optionname=0x8623e2a "bindto",
optionvalue=0xbf866d04) at
php-5.3.0RC3/main/streams/streams.c:2036
#1 0x082ef2e3 in php_tcp_sockop_set_option (stream=0xa2eac68,
option=7, value=0, ptrparam=0xbf866dd0)
at php-5.3.0RC3/main/streams/xp_socket.c:641
#2 0x082e27d2 in _php_stream_set_option (stream=0xa2eac68, option=7,
value=0, ptrparam=0xbf866dd0)
at php-5.3.0RC3/main/streams/streams.c:1175
#3 0x082ed90f in php_stream_xport_connect (stream=0xa2eac68,
name=0xa2eac16 "example.com:80", namelen=16, asynchronous=0,
timeout=0xbf866e84, error_text=0xbf866e8c, error_code=0x0) at
php-5.3.0RC3/main/streams/transports.c:230
#4 0x082edcca in _php_stream_xport_create (name=0xa2eac16
"example.org:80", namelen=16, options=12, flags=0,
#44098 [Asn->Fbk]: imap_utf8() returns only capital letters
ID: 44098
Updated by: paj...@php.net
Reported By: steffen at dislabs dot de
-Status: Assigned
+Status: Feedback
Bug Type: IMAP related
Operating System: FreeBSD 6.2
PHP Version: 5.2.5
Assigned To: pajoye
New Comment:
hi,
The patch should be against configure.in not configure. Can you update
it again please?
Previous Comments:
[2009-12-23 15:16:54] sebastian dot gerlach at digionline dot de
http://digionline.de/sebastian.gerlach/imap-capital-letters.patch
# patch -p0 -i imap-capital-letters.patch
[2009-12-22 20:20:48] paj...@php.net
Can you provide a link to the patch please?
[2009-12-22 18:00:11] sebastian dot gerlach at digionline dot de
Complete patch for 5.3.1:
*** configure 2009-11-18 21:11:57.0 +0100
--- configure.new 2009-12-22 18:36:30.0 +0100
***
*** 47697,47703
CFLAGS="-I$IMAP_INC_DIR"
echo $ac_n "checking for U8T_CANONICAL""... $ac_c" 1>&6
echo "configure:47700: checking for U8T_CANONICAL" >&5
! if eval "test \"`echo '$''{'ac_cv_u8t_canonical'+set}'`\" = set";
then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <&6
echo "configure:47700: checking for U8T_CANONICAL" >&5
! if eval "test \"`echo '$''{'ac_cv_u8t_decompose'+set}'`\" = set";
then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <&5; (eval
$ac_compile) 2>&5; }; then
rm -rf conftest*
! ac_cv_u8t_canonical=yes
else
echo "configure: failed program was:" >&5
cat conftest.$ac_ext >&5
rm -rf conftest*
! ac_cv_u8t_canonical=no
fi
rm -f conftest*
fi
! echo "$ac_t""$ac_cv_u8t_canonical" 1>&6
CFLAGS=$old_CFLAGS
! if test "$ac_cv_u8t_canonical" = "no" && test
"$ac_cv_utf8_mime2text" = "new"; then
{ echo "configure: error: utf8_mime2text() has new signature,
but
U8T_CANONICAL is missing. This should not happen. Check config.log for
additional information." 1>&2; exit 1; }
fi
! if test "$ac_cv_u8t_canonical" = "yes" && test
"$ac_cv_utf8_mime2text" = "old"; then
{ echo "configure: error: utf8_mime2text() has old signature,
but
U8T_CANONICAL is present. This should not happen. Check config.log for
additional information." 1>&2; exit 1; }
fi
--- 47715,47741
if { (eval echo configure:47716: \"$ac_compile\") 1>&5; (eval
$ac_compile) 2>&5; }; then
rm -rf conftest*
! ac_cv_u8t_decompose=yes
else
echo "configure: failed program was:" >&5
cat conftest.$ac_ext >&5
rm -rf conftest*
! ac_cv_u8t_decompose=no
fi
rm -f conftest*
fi
! echo "$ac_t""$ac_cv_u8t_decompose" 1>&6
CFLAGS=$old_CFLAGS
! if test "$ac_cv_u8t_decompose" = "no" && test
"$ac_cv_utf8_mime2text" = "new"; then
{ echo "configure: error: utf8_mime2text() has new signature,
but
U8T_CANONICAL is missing. This should not happen. Check config.log for
additional information." 1>&2; exit 1; }
fi
! if test "$ac_cv_u8t_decompose" = "yes" && test
"$ac_cv_utf8_mime2text" = "old"; then
{ echo "configure: error: utf8_mime2text() has old signature,
but
U8T_CANONICAL is present. This should not happen. Check config.log for
additional information." 1>&2; exit 1; }
fi
*** ext/imap/config.m4 2009-05-05 03:22:44.0 +0200
--- ext/imap/config.m4.new 2009-12-22 18:39:16.0 +0100
***
*** 147,169
old_CFLAGS=$CFLAGS
CFLAGS="-I$IMAP_INC_DIR"
! AC_CACHE_CHECK(for U8T_CANONICAL, ac_cv_u8t_canonical,
AC_TRY_COMPILE([
#include
],[
int i = U8T_CANONICAL;
],[
! ac_cv_u8t_canonical=yes
],[
! ac_cv_u8t_canonical=no
])
)
CFLAGS=$old_CFLAGS
! if test "$ac_cv_u8t_canonical" = "no" && test
"$ac_cv_utf8_mime2text" = "new"; then
AC_MSG_ERROR([utf8_mime2text() has new signature, but
U8T_CANONICAL
is missing. This should not happen. Check config.log for additional
information.])
fi
! if test "$ac_cv_u8t_canonical" = "yes" && test
"$ac_cv_utf8_mime2text" = "old"; then
AC_MSG_ERROR([utf8_mime2text() has old signature, but
U8T_CANONICAL
is present. This should not happen. Check config.log for additional
information.])
fi
--- 147,169
old_CFLAGS=$CFLAGS
CFLAGS="-I$IMAP_INC_DIR"
! AC_CACHE_CHECK(for U8T_DECOMPOSE, ac_cv_u8t_canonical,
AC_TRY_COMPILE([
#include
],[
int i = U8T_CANONICAL;
],[
! ac_cv_u8t_decompose=yes
],[
! ac_cv_u8t_decompose=no
])
)
C
#33500 [Asn->Csd]: imap_open() fails when the server advertises GSSAPI
ID: 33500
Updated by: paj...@php.net
Reported By: ed2019 at columbia dot edu
-Status: Assigned
+Status: Closed
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-01-05 01:12:19] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=293126
Log: - [doc] add support for DISABLE_AUTHENTICATOR in imap_open (fix
#33500)
[2010-01-05 01:02:16] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=293124
Log: - [doc] fix exchange and other imap server support when a
preferred auth method is not desired. Add option support to imap_open.
Only 'DISABLE_AUTHENTICATOR' is supported yet, see #33500 for an example
[2009-11-04 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-11-02 16:22:40] nick at mailtrust dot com
It looks like you may have forgotten to add the following to your
patch:
Index: php_imap.c
===
--- php_imap.c(revision 3434)
+++ php_imap.c(working copy)
@@ -105,6 +105,7 @@
ZEND_BEGIN_ARG_INFO_EX(arginfo_imap_open, 0, 0, 3)
ZEND_ARG_INFO(0, mailbox)
ZEND_ARG_INFO(0, user)
ZEND_ARG_INFO(0, password)
ZEND_ARG_INFO(0, options)
ZEND_ARG_INFO(0, n_retries)
+ ZEND_ARG_INFO(0, params)
ZEND_END_ARG_INFO()
This should allow for a max of 6 arguments instead of just 5.
[2009-10-27 11:24:31] paj...@php.net
It sounds like the patch was not applied then. It clearly takes 3 or 6
parameters:
+ if (zend_parse_parameters(argc TSRMLS_CC, "sss|lla", &mailbox,
&mailbox_len, &user, &user_len,
+ &passwd, &passwd_len, &flags, &retries, ¶ms) == FAILURE) {
Can you verify that the patch was actually applied?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/33500
--
Edit this bug report at http://bugs.php.net/?id=33500&edit=1
#33500 [NoF->Asn]: imap_open() fails when the server advertises GSSAPI
ID: 33500
Updated by: paj...@php.net
Reported By: ed2019 at columbia dot edu
-Status: No Feedback
+Status: Assigned
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.2.9
Assigned To: pajoye
Previous Comments:
[2009-11-04 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-11-02 16:22:40] nick at mailtrust dot com
It looks like you may have forgotten to add the following to your
patch:
Index: php_imap.c
===
--- php_imap.c(revision 3434)
+++ php_imap.c(working copy)
@@ -105,6 +105,7 @@
ZEND_BEGIN_ARG_INFO_EX(arginfo_imap_open, 0, 0, 3)
ZEND_ARG_INFO(0, mailbox)
ZEND_ARG_INFO(0, user)
ZEND_ARG_INFO(0, password)
ZEND_ARG_INFO(0, options)
ZEND_ARG_INFO(0, n_retries)
+ ZEND_ARG_INFO(0, params)
ZEND_END_ARG_INFO()
This should allow for a max of 6 arguments instead of just 5.
[2009-10-27 11:24:31] paj...@php.net
It sounds like the patch was not applied then. It clearly takes 3 or 6
parameters:
+ if (zend_parse_parameters(argc TSRMLS_CC, "sss|lla", &mailbox,
&mailbox_len, &user, &user_len,
+ &passwd, &passwd_len, &flags, &retries, ¶ms) == FAILURE) {
Can you verify that the patch was actually applied?
[2009-10-27 11:19:12] b dot parnell at abertay dot ac dot uk
I have tried the patch and keep getting the error:
Warning: Wrong parameter count for imap_open()
I am using Ubuntu 9.04 and am compiling against the php 5.3.0 source
with the associated patch applied and with the
./configure --with-imap --with-kerberos --with-imap-ssl
initial command, make clean;make all;make install is the next commands
I execute.
I have also tried the source 5.3.1RC2 and this gives the error:
Warning: imap_open() expects at most 5 parameters, 6 given
If someone has managed to get this to work please provide a copy of the
binaries until the release is rolled out to apt.
Am I missing something here?
Best Regards,
Bill
[2009-10-05 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/33500
--
Edit this bug report at http://bugs.php.net/?id=33500&edit=1
#49960 [Opn->Csd]: Add INTERNALDATE to imap_append
ID: 49960
Updated by: paj...@php.net
Reported By: nick at mailtrust dot com
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: CentOS 5
PHP Version: 5.3SVN-2009-10-22 (SVN)
-Assigned To:
+Assigned To: pajoye
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-12-07 18:56:16] nick at mailtrust dot com
Is there any update on when/if this patch will make it in an upcoming
release?
Thanks,
Nick
[2009-10-22 16:34:50] nick at mailtrust dot com
Description:
Jake Levitt and I created this patch which adds the option to set a
message's INTERNALDATE when appending it to a mail server using imap.
Any chance we can get this included into the php 5.3 and 6 development
branches? The diff below was done against the php-src/branches/PHP_5_3
branch. If you guys need me to apply the changes to a different branch
or snapshot, please let me know.
Here's the svn diff (done in my repo)... if you need something else
please let me know:
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c (revision 3399)
+++ ext/imap/php_imap.c (working copy)
@@ -41,6 +41,7 @@
#include "ext/standard/info.h"
#include "ext/standard/file.h"
#include "ext/standard/php_smart_str.h"
+#include "ext/pcre/php_pcre.h"
#ifdef ERROR
#undef ERROR
@@ -118,6 +119,7 @@
ZEND_ARG_INFO(0, folder)
ZEND_ARG_INFO(0, message)
ZEND_ARG_INFO(0, options)
+ ZEND_ARG_INFO(0, date)
ZEND_END_ARG_INFO()
ZEND_BEGIN_ARG_INFO_EX(arginfo_imap_num_msg, 0, 0, 1)
@@ -1265,25 +1267,48 @@
}
/* }}} */
-/* {{{ proto bool imap_append(resource stream_id, string folder,
string message [, string options])
+/* {{{ proto bool imap_append(resource stream_id, string folder,
string message [, string options [, string internal_date]])
Append a new message to a specified mailbox */
PHP_FUNCTION(imap_append)
{
zval *streamind;
- char *folder, *message, *flags = NULL;
- int folder_len, message_len, flags_len = 0;
+ char *folder, *message, *internal_date = NULL, *flags = NULL;
+ int folder_len, message_len, internal_date_len = 0, flags_len = 0;
pils *imap_le_struct;
STRING st;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rss|s",
&streamind, &folder, &folder_len, &message, &message_len, &flags,
&flags_len) == FAILURE) {
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rss|ss",
&streamind, &folder, &folder_len, &message, &message_len, &flags,
&flags_len, &internal_date, &internal_date_len) == FAILURE) {
return;
}
+ char* regex = "/[
0-3][0-9]-((Jan)|(Feb)|(Mar)|(Apr)|(May)|(Jun)|(Jul)|(Aug)|(Sep)|(Oct)|(Nov)|(Dec))-[0-9]{4}
[0-2][0-9]:[0-5][0-9]:[0-5][0-9] [+-][0-9]{4}/";
+ int regex_len = strlen(regex);
+ pcre_cache_entry *pce; /* Compiled regex */
+ zval *subpats = NULL; /* Parts (not used) */
+ long regex_flags = 0; /* Flags (not used) */
+ long start_offset = 0; /* Start offset (not
used) */
+ int global = 0;
+
+ if (internal_date) {
+ /* Make sure the given internal_date string matches the RFC
specified format */
+ if ((pce = pcre_get_compiled_regex_cache(regex, regex_len
TSRMLS_CC)) == NULL) {
+ RETURN_FALSE;
+ }
+
+ php_pcre_match_impl(pce, internal_date, internal_date_len,
return_value, subpats, global,
+ 0, regex_flags, start_offset TSRMLS_CC);
+
+ if (!Z_LVAL_P(return_value)) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, "internal
date not
correctly formatted");
+ internal_date = NULL;
+ }
+ }
+
ZEND_FETCH_RESOURCE(imap_le_struct, pils *, &streamind, -1, "imap",
le_imap);
INIT (&st, mail_string, (void *) message, message_len);
- if (mail_append_full(imap_le_struct->imap_stream, folder, (flags ?
flags : NIL), NIL, &st)) {
+ if (mail_append_full(imap_le_struct->imap_stream, folder, (flags ?
flags : NIL), (internal_date ? internal_date : NIL), &st)) {
RETURN_TRUE;
} else {
RETURN_FALSE;
--
Edit this bug report at http://bugs.php.net/?id=49960&edit=1
#50663 [Opn->Bgs]: exec and shell_exec don't works with msginit
ID: 50663 Updated by: ras...@php.net Reported By: samuel dot roze at gmail dot com -Status: Open +Status: Bogus Bug Type: Program Execution Operating System: Debian 5 PHP Version: 5.3.1 New Comment: Sorry, but these types of issues are never PHP-related. You just proved it yourself that when you ran PHP in a cli environment, it worked fine. But in the Apache environment it didn't. Therefore it has to do with something in your Apache environment. Like environment variables, LOCALE, or maybe even a requirement for a controlling tty, or something along those lines. Regardless, it has nothing to do with PHP. strace the working one and compare it to the strace of the non- working one and figure out what is going on. Previous Comments: [2010-01-04 22:39:36] samuel dot roze at gmail dot com Notice: This PHP test work when using the "php file.php" command but no on Apache. With the command, the message "/home/samuel/Développement/workspaces/PHP/GetTextEdit/tests/php/file.po a été créé." is printed on the shell, nothing is sent to PHP. [2010-01-04 22:23:19] samuel dot roze at gmail dot com Description: The function exec or the shell_exec function are not working with the msginit (gettext) program. Reproduce code: --- Create an empty "/home/user/file.pot" file. Expected result: string(X) "/home/d-sites/myonlinessh/includes/locales/ps_AK/messages a été créé." and that the file.po file was created. Actual result: -- string(0) "" and the file.po doesn't exists. Note: there's any error and the same command, with the www-data user (used by Apache) works in my shell! -- Edit this bug report at http://bugs.php.net/?id=50663&edit=1
#50661 [Opn]: DOMDocument::loadXML does not allow UTF-16
ID: 50661 Updated by: rricha...@php.net Reported By: geoffers+phpbugs at gmail dot com Status: Open Bug Type: DOM XML related Operating System: Mac OS 10.5.8 PHP Version: 5.3SVN-2010-01-04 (SVN) -Assigned To: +Assigned To: rrichards New Comment: Assign to self Previous Comments: [2010-01-04 20:58:36] geoffers+phpbugs at gmail dot com Description: DOMDocument::loadXML() does not support UTF-16 encoded XML. This breaks the XML spec which says, "All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode". As such, DOMDocument::loadXML() is not a conformant XML processor. XMLReader supports this fine, which suggests something is wrong in the use of the libxml2 API. Reproduce code: --- loadXML($data); echo $dom->saveXML(); Expected result: Actual result: -- PHP Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=50661&edit=1
#50657 [Opn->Ana]: copy() with an empty (zero-byte) HTTP source succeeds but returns false
ID: 50657
Updated by: j...@php.net
Reported By: php at lorddeath dot net
-Status: Open
+Status: Analyzed
Bug Type: Filesystem function related
Operating System: Win32/Linux
PHP Version: 5.3SVN-2010-01-04 (snap)
New Comment:
_php_stream_copy_to_stream_ex() contains the problem, it assumes read
length of 0 to be an error..
Previous Comments:
[2010-01-04 21:57:30] j...@php.net
Nevermind, the auto-link-thing in this crappy bug tracker messed the
url. :)
[2010-01-04 21:56:47] j...@php.net
Was the file always returning 404 ?
[2010-01-04 15:51:34] php at lorddeath dot net
Description:
The copy() function returns false (but otherwise succeeds in copying
the
file) when the source file is accessed via a HTTP stream, but is empty
(zero bytes). Other, non-HTTP, stream types might also be affected,
but
local files are definitely *NOT* affected.
I have successfully reproduced this bug with PHP 5.2.9 on Linux, and
5.2.5, 5.2.12, 5.3.0, 5.3.1 and 5.3.3-dev (2010-Jan-04 15:00:00) on
Windows.
(I will keep the empty.txt URL in the reproduce code accessible for a
while.)
Reproduce code:
---
$r = copy("http://lspace.sihnon.net/pub/empty.txt";, "temp");
var_dump($r);
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=50657&edit=1
#50663 [Com]: exec and shell_exec don't works with msginit
ID: 50663 Comment by: samuel dot roze at gmail dot com Reported By: samuel dot roze at gmail dot com Status: Open Bug Type: Program Execution Operating System: Debian 5 PHP Version: 5.3.1 New Comment: Notice: This PHP test work when using the "php file.php" command but no on Apache. With the command, the message "/home/samuel/Développement/workspaces/PHP/GetTextEdit/tests/php/file.po a été créé." is printed on the shell, nothing is sent to PHP. Previous Comments: [2010-01-04 22:23:19] samuel dot roze at gmail dot com Description: The function exec or the shell_exec function are not working with the msginit (gettext) program. Reproduce code: --- Create an empty "/home/user/file.pot" file. Expected result: string(X) "/home/d-sites/myonlinessh/includes/locales/ps_AK/messages a été créé." and that the file.po file was created. Actual result: -- string(0) "" and the file.po doesn't exists. Note: there's any error and the same command, with the www-data user (used by Apache) works in my shell! -- Edit this bug report at http://bugs.php.net/?id=50663&edit=1
#50663 [NEW]: exec and shell_exec don't works with msginit
From: samuel dot roze at gmail dot com Operating system: Debian 5 PHP version: 5.3.1 PHP Bug Type: Program Execution Bug description: exec and shell_exec don't works with msginit Description: The function exec or the shell_exec function are not working with the msginit (gettext) program. Reproduce code: --- Create an empty "/home/user/file.pot" file. Expected result: string(X) "/home/d-sites/myonlinessh/includes/locales/ps_AK/messages a été créé." and that the file.po file was created. Actual result: -- string(0) "" and the file.po doesn't exists. Note: there's any error and the same command, with the www-data user (used by Apache) works in my shell! -- Edit bug report at http://bugs.php.net/?id=50663&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50663&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50663&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50663&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50663&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50663&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50663&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50663&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50663&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50663&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50663&r=support Expected behavior: http://bugs.php.net/fix.php?id=50663&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50663&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50663&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50663&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50663&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50663&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50663&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50663&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50663&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50663&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50663&r=mysqlcfg
#50662 [NEW]: New directive expression_tags
From: joseberardo at gmail dot com Operating system: all PHP version: 6SVN-2010-01-04 (snap) PHP Bug Type: Feature/Change Request Bug description: New directive expression_tags Description: The directive short_tags is deprecated and should not be disponible in 6th major version. But, it brings expression tags (http://bugs.php.net/?id=50662&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50662&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50662&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50662&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50662&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50662&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50662&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50662&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50662&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50662&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50662&r=support Expected behavior: http://bugs.php.net/fix.php?id=50662&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50662&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50662&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50662&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50662&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50662&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50662&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50662&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50662&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50662&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50662&r=mysqlcfg
#50657 [Fbk->Opn]: copy() with an empty (zero-byte) HTTP source succeeds but returns false
ID: 50657
Updated by: j...@php.net
Reported By: php at lorddeath dot net
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Win32/Linux
PHP Version: 5.3SVN-2010-01-04 (snap)
New Comment:
Nevermind, the auto-link-thing in this crappy bug tracker messed the
url. :)
Previous Comments:
[2010-01-04 21:56:47] j...@php.net
Was the file always returning 404 ?
[2010-01-04 15:51:34] php at lorddeath dot net
Description:
The copy() function returns false (but otherwise succeeds in copying
the
file) when the source file is accessed via a HTTP stream, but is empty
(zero bytes). Other, non-HTTP, stream types might also be affected,
but
local files are definitely *NOT* affected.
I have successfully reproduced this bug with PHP 5.2.9 on Linux, and
5.2.5, 5.2.12, 5.3.0, 5.3.1 and 5.3.3-dev (2010-Jan-04 15:00:00) on
Windows.
(I will keep the empty.txt URL in the reproduce code accessible for a
while.)
Reproduce code:
---
$r = copy("http://lspace.sihnon.net/pub/empty.txt";, "temp");
var_dump($r);
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=50657&edit=1
#50657 [Opn->Fbk]: copy() with an empty (zero-byte) HTTP source succeeds but returns false
ID: 50657
Updated by: j...@php.net
Reported By: php at lorddeath dot net
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Win32/Linux
PHP Version: 5.3SVN-2010-01-04 (snap)
New Comment:
Was the file always returning 404 ?
Previous Comments:
[2010-01-04 15:51:34] php at lorddeath dot net
Description:
The copy() function returns false (but otherwise succeeds in copying
the
file) when the source file is accessed via a HTTP stream, but is empty
(zero bytes). Other, non-HTTP, stream types might also be affected,
but
local files are definitely *NOT* affected.
I have successfully reproduced this bug with PHP 5.2.9 on Linux, and
5.2.5, 5.2.12, 5.3.0, 5.3.1 and 5.3.3-dev (2010-Jan-04 15:00:00) on
Windows.
(I will keep the empty.txt URL in the reproduce code accessible for a
while.)
Reproduce code:
---
$r = copy("http://lspace.sihnon.net/pub/empty.txt";, "temp");
var_dump($r);
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=50657&edit=1
#50652 [WFx->Ana]: time call optimization
ID: 50652 Updated by: ras...@php.net Reported By: robert_xp at gmx dot net -Status: Wont fix +Status: Analyzed Bug Type:Performance problem PHP Version: 5.3.1 New Comment: I'm not completely against this one. At Yahoo we replaced the expensive gettimeofday syscalls with a fast system-wide replacement so it wasn't just PHP that benefitted. They are not insignificant and since the bulk of scripts do run as quick web requests where it is perfectly fine for all time calls to get the request timestamp, and sometimes it even fixes edge-case bugs when they do, so the idea of having some sort switch to enable this optimization is not bad. We would probably have to keep the default as it is though to avoid any BC breaks. Previous Comments: [2010-01-04 15:26:50] robert_xp at gmx dot net I'm such an idiot. Sorry, fixed. [2010-01-04 15:19:35] ras...@php.net Your patch it also reversed. [2010-01-04 15:11:49] robert_xp at gmx dot net Yes, that's right. I think this is the only point, that speaks really against this solution but most scripts should be executed in < 0.x sec and calling time(NULL) many times can be optimized this way. A good improvement could be, applying the patch and change the SAPI handling to check against a config variable if a optimized time handling should be used - with default using the old approach. [2010-01-04 12:25:31] der...@php.net We can't do this, as for longer running scripts the value as returned by time() can change (like once every second). [2010-01-04 12:18:06] robert_xp at gmx dot net Description: Sure, it is not so critical to patch this but you use ever time(NULL) to get the current time in most functions. There is a better way going over the SAPI interface and retrieve a cached value. I published also a patch for all time(NULL/0) calls on http://www.xarg.org/2009/12/php-hacking/ I also hacked the FCGI sapi to get the time value direclty from the webserver - yes it is not supported by default. -- Edit this bug report at http://bugs.php.net/?id=50652&edit=1
#50661 [NEW]: DOMDocument::loadXML does not allow UTF-16
From: geoffers+phpbugs at gmail dot com Operating system: Mac OS 10.5.8 PHP version: 5.3SVN-2010-01-04 (SVN) PHP Bug Type: DOM XML related Bug description: DOMDocument::loadXML does not allow UTF-16 Description: DOMDocument::loadXML() does not support UTF-16 encoded XML. This breaks the XML spec which says, "All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode". As such, DOMDocument::loadXML() is not a conformant XML processor. XMLReader supports this fine, which suggests something is wrong in the use of the libxml2 API. Reproduce code: --- loadXML($data); echo $dom->saveXML(); Expected result: Actual result: -- PHP Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 -- Edit bug report at http://bugs.php.net/?id=50661&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50661&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50661&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50661&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50661&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50661&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50661&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50661&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50661&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50661&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50661&r=support Expected behavior: http://bugs.php.net/fix.php?id=50661&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50661&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50661&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50661&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50661&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50661&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50661&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50661&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50661&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50661&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50661&r=mysqlcfg
#47412 [Com]: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
ID: 47412 Comment by: tser at deltacontrols dot com Reported By: tser at deltacontrols dot com Status: Feedback Bug Type: CGI related Operating System: win32 only - Vista PHP Version: 5.2.9RC2 Assigned To: pajoye New Comment: To answer the question, the values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests ar eboth 1. But they do not come into play to duplicate this problem. The problem could be duplicated before number of request reach these numbers. I will try to explain the detail using just the standard extension (php_date). 1. Setup PHP FactCGI in IIS. Everything default. 2. Try to run a test.php with this code 3. Attach the debugger to php_cgi.exe and make sure it loaded the debug symbol of php_date. 4. Put a break point in PHP_MSHUTDOWN_FUNCTION inside php_date.c 5. Go to IIS Manager, Application Pools. Select DefaultAppPool and click "Recycle..." on the right hand pane. 6. Notice that the php_cgi.exe will exit but your breakpoint in php_date.c is not triggered. Previous Comments: [2010-01-04 14:00:54] paj...@php.net It is called as expected (tested on vista/iis and in the console). If you still experiece this problem, then please provide a detailed way to reproduce: - what are you doing exactly in IIS - values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests (IIS setting) [2009-12-23 02:27:19] paj...@php.net Will verify this issue once I'm back from vacation. [2009-12-23 02:15:37] liak dot liang at gmail dot com Have the same problem in PHP5.3.0 [2009-04-21 19:30:20] tser at deltacontrols dot com 5.2.10 (April 21) has the same problem. [2009-04-21 17:08:54] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47412 -- Edit this bug report at http://bugs.php.net/?id=47412&edit=1
#50660 [NEW]: exif_read_data fails on a given image while giving no errors with other tools
From: skinny dot bravo at gmail dot com
Operating system: Linux
PHP version: 5.2.12
PHP Bug Type: EXIF related
Bug description: exif_read_data fails on a given image while giving no errors
with other tools
Description:
PHP fails reading GPS data from a given set of photos from Samsung SGH-
i900. The images are said to come from the camera without any edits.
Ex:
http://o1.imgsrc.ru/v/vahmurka/3/16095163cDU.jpg
http://o1.imgsrc.ru/v/vahmurka/1/16095161rno.jpg
exiftool 8.00 has no problem reading this file. php5.2-201001041530
produces
the same result.
Reproduce code:
---
# php -r 'var_dump(read_exif_data("16095163cDU.jpg",NULL,TRUE));'
Expected result:
...
["SectionsFound"]=>
string(35) "ANY_TAG, IFD0, THUMBNAIL, EXIF, GPS"
...
["GPS"]=>
array(8) {
["GPSVersion"]=>
string(4) ""
["GPSLatitudeRef"]=>
string(1) "N"
["GPSLatitude"]=>
array(3) {
[0]=>
string(4) "43/1"
[1]=>
string(4) "16/1"
[2]=>
string(11) "75363/1"
}
["GPSLongitudeRef"]=>
string(1) "E"
["GPSLongitude"]=>
array(3) {
[0]=>
string(4) "77/1"
[1]=>
string(4) "21/1"
[2]=>
string(11) "140249/2629"
}
["GPSAltitudeRef"]=>
string(1) ""
["GPSAltitude"]=>
string(6) "1603/1"
["GPSMapDatum"]=>
string(6) "WGS-84"
}
these results are taken after fixing image with exiftool:
# exiftool -all= -tagsfromfile @ -all:all -unsafe 16095163cDU.jpg
Actual result:
--
Warning: read_exif_data(16095163cDU.jpg): Illegal IFD offset in
Command line code on line 1
array(4) {
["FILE"]=>
array(6) {
["FileName"]=>
string(15) "16095163cDU.jpg"
["FileDateTime"]=>
int(1259257839)
["FileSize"]=>
int(938692)
["FileType"]=>
int(2)
["MimeType"]=>
string(10) "image/jpeg"
["SectionsFound"]=>
string(19) "ANY_TAG, IFD0, EXIF"
}
--
Edit bug report at http://bugs.php.net/?id=50660&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50660&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50660&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50660&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50660&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50660&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50660&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50660&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50660&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50660&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50660&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50660&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50660&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50660&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50660&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50660&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50660&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50660&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50660&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50660&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50660&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50660&r=mysqlcfg
#50659 [NEW]: Junctions over a share fail
From: RQuadling at GMail dot com
Operating system: Windows XP SP3
PHP version: 5.3SVN-2010-01-04 (snap)
PHP Bug Type: Directory function related
Bug description: Junctions over a share fail
Description:
realpath() returns false for files inside junctions inside a share
accessed using a relative path.
Ok. I _did_ say this was an edge case.
The code below is an batch script utilising Windows NET SHARE and NET
MAP commands to create a drive J: mapped to C:\RAQ_Share and the
JUNCTION program from System Internals to create a junction in that
share.
The last few lines relate specifically to PHP.
Essentially absolute paths are realpath()-able just fine, but relative
paths are not.
Reproduce code:
---
@ECHO OFF
ECHO Create Original directory and file.
MD C:\RAQ_Orig
ECHO This is the file. > C:\RAQ_Orig\File.txt
ECHO.
ECHO Create share
MD C:\RAQ_Share
NET SHARE RAQ_Shared=C:\RAQ_Share /UNLIMITED
ECHO.
ECHO Map share
@NET USE J: /D > NUL
NET USE J: \\%COMPUTERNAME%\RAQ_Shared
ECHO.
ECHO Create junction
MD J:\RAQ_Junc
JUNCTION J:\RAQ_Junc C:\RAQ_Orig
ECHO.
ECHO Show the folders.
DIR \RAQ*
ECHO.
ECHO See contents of junction
DIR J:\RAQ_Junc\File.txt
ECHO.
ECHO Use PHP to report realpaths
PHP -v
PHP -n -r "var_dump(realpath('J:/RAQ_Junc/File.txt'));"
CD /D J:\
PHP -n -r "var_dump(realpath('/RAQ_Junc/File.txt'));"
CD \RAQ_Junc
PHP -n -r "var_dump(realpath('./File.txt'));"
Expected result:
Create Original directory and file.
Create share
RAQ_Shared was shared successfully.
Drop and map share
J: was deleted successfully.
The command completed successfully.
Create junction
Junction v1.05 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2007 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: J:\RAQ_Junc
Targetted at: C:\RAQ_Orig
Show the folders.
Volume in drive C has no label.
Volume Serial Number is 1044-5992
Directory of C:\
2010/01/04 17:47 RAQ_Orig
2010/01/04 17:47 RAQ_Share
0 File(s) 0 bytes
2 Dir(s) 11,663,155,200 bytes free
See contents of junction
Volume in drive J has no label.
Volume Serial Number is 1044-5992
Directory of J:\RAQ_Junc
2010/01/04 17:4720 File.txt
1 File(s) 20 bytes
0 Dir(s) 11,663,155,200 bytes free
Use PHP to report realpaths
PHP 5.3.3-dev (cli) (built: Jan 4 2010 12:59:42)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
string(20) "C:\RAQ_Orig\File.txt"
string(20) "C:\RAQ_Orig\File.txt"
string(20) "C:\RAQ_Orig\File.txt"
Actual result:
--
Create Original directory and file.
Create share
RAQ_Shared was shared successfully.
Drop and map share
J: was deleted successfully.
The command completed successfully.
Create junction
Junction v1.05 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2007 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: J:\RAQ_Junc
Targetted at: C:\RAQ_Orig
Show the folders.
Volume in drive C has no label.
Volume Serial Number is 1044-5992
Directory of C:\
2010/01/04 17:47 RAQ_Orig
2010/01/04 17:47 RAQ_Share
0 File(s) 0 bytes
2 Dir(s) 11,663,155,200 bytes free
See contents of junction
Volume in drive J has no label.
Volume Serial Number is 1044-5992
Directory of J:\RAQ_Junc
2010/01/04 17:4720 File.txt
1 File(s) 20 bytes
0 Dir(s) 11,663,155,200 bytes free
Use PHP to report realpaths
PHP 5.3.3-dev (cli) (built: Jan 4 2010 12:59:42)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
string(20) "C:\RAQ_Orig\File.txt"
string(20) "C:\RAQ_Orig\File.txt"
bool(false)
--
Edit bug report at http://bugs.php.net/?id=50659&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50659&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50659&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50659&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50659&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50659&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50659&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50659&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50659&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50659&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50659&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50659&r=notwrong
Not enough info:
#50649 [Opn]: negative offsets
ID: 50649 Updated by: ahar...@php.net Reported By: robert_xp at gmx dot net Status: Open Bug Type:Feature/Change Request PHP Version: 5.3.1 New Comment: For reference, functionality similar to this has been discussed at least once before on the Internals mailing list: http://marc.info/?l=php-internals&m=119123827510426&w=2 I'm not going to Won't Fix this, because unlike bug #50647, this hasn't been denied via the RFC process. I'd suggest that writing an RFC to start a discussion on Internals is probably the right way to go about this (being a language change), rather than a feature request here. Previous Comments: [2010-01-04 11:55:48] robert_xp at gmx dot net Description: I heared somewhere, that string offsets will be removed in future releases of PHP, as of 6.0. I like accessing single characters in a C/C++ like way. If you pass a negative offset to strings, it would be a good improvement to start at the end of the string, like the behavior of substr(). The same is also possible for arrays, but I only focused on string offsets here: http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- $str = "Hello"; echo $str[-2].$str[-1].$str[0]; Expected result: loH Actual result: -- Warnings -- Edit this bug report at http://bugs.php.net/?id=50649&edit=1
#50647 [WFx]: Short array notation
ID: 50647 Updated by: ahar...@php.net Reported By: robert_xp at gmx dot net Status: Wont fix Bug Type:Feature/Change Request PHP Version: 5.3.1 New Comment: If you really, really, really want to reopen that can of worms, take it to the Internals mailing list. At best, you'll get a few suggestions to write a fresh RFC for possible inclusion in PHP 6. More likely, you'll get pointed to the same link I've pointed you to. If you do this, bear in mind that it's been discussed many times over the years, and has been rejected each and every time. To whit, a possibly complete list of previous mailing list discussions back to the start of 2006: December 2008: http://marc.info/?l=php-internals&m=122956025230147&w=2 May 2008: http://marc.info/?l=php-internals&m=121142241913674&w=2 January 2008: http://marc.info/?l=php-internals&m=12917517840&w=2 and http://marc.info/?l=php-internals&m=119995972028293&w=2 February 2007: http://marc.info/?l=php-internals&m=117057393530217&w=2 January 2006: http://marc.info/?l=php-internals&m=113851593906799&w=2 The (extremely lengthy) May 2008 discussion was the one that led to the RFC. In short, this is pretty much in the same boat as being able to directly dereference array returned from functions, or ifsetor, or taint support, or some of the other regularly requested features that don't spring to mind at 12:07 on a Tuesday morning: it comes up on a regular basis, and while you and I may or may not agree with the decisions that have been made, they've been made, and I don't know that anyone will thank you for reopening a debate that's been had many times over. Previous Comments: [2010-01-04 15:32:42] robert_xp at gmx dot net Grml...Sorry, I didn't saw this before. I read the mailing lists, but I couldn't find a justification why this feature is declined. Most userspace votes were positive, and I added this feature independent from these discussions - maybe open another vote with more parts? [2010-01-04 12:27:25] ahar...@php.net This has already gone through the RFC process and been declined, per http://wiki.php.net/rfc/shortsyntaxforarrays [2010-01-04 11:46:29] robert_xp at gmx dot net Description: A nice improvement for PHP would be a short hand notation for arrays. You can find more details here: http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- //old: $arr = array(1, 2, array(5 => "foo", 3.14159), 9); //new: $arr = [1, 2, [5 => "foo", 3.14159], 9]; Expected result: In both cases the result of $arr should be the same. Actual result: -- Compile-error -- Edit this bug report at http://bugs.php.net/?id=50647&edit=1
#50656 [Opn->Bgs]: Assign constant to var causes syntax error
ID: 50656 Updated by: johan...@php.net Reported By: willirl at gmail dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: mac os x 10.6 PHP Version: 5.3.1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Drop the "var" keyword. Previous Comments: [2010-01-04 15:07:07] willirl at gmail dot com Description: This error is on Mac 10.6 has PHP 5.3.0 which is not shown in version selector. The code causes this error: Parse error: syntax error, unexpected T_VAR in /Users/willirl/Desktop/TEST Files/test.php on line 6 Reproduce code: --- Expected result: No error. $abc set to 25. -- Edit this bug report at http://bugs.php.net/?id=50656&edit=1
#50657 [NEW]: copy() with an empty (zero-byte) HTTP source succeeds but returns false
From: php at lorddeath dot net
Operating system: Win32/Linux
PHP version: 5.3SVN-2010-01-04 (snap)
PHP Bug Type: Filesystem function related
Bug description: copy() with an empty (zero-byte) HTTP source succeeds but
returns false
Description:
The copy() function returns false (but otherwise succeeds in copying the
file) when the source file is accessed via a HTTP stream, but is empty
(zero bytes). Other, non-HTTP, stream types might also be affected, but
local files are definitely *NOT* affected.
I have successfully reproduced this bug with PHP 5.2.9 on Linux, and
5.2.5, 5.2.12, 5.3.0, 5.3.1 and 5.3.3-dev (2010-Jan-04 15:00:00) on
Windows.
(I will keep the empty.txt URL in the reproduce code accessible for a
while.)
Reproduce code:
---
$r = copy("http://lspace.sihnon.net/pub/empty.txt";, "temp");
var_dump($r);
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit bug report at http://bugs.php.net/?id=50657&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50657&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50657&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50657&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50657&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50657&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50657&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50657&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50657&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50657&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50657&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50657&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50657&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50657&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50657&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50657&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50657&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50657&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50657&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50657&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50657&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50657&r=mysqlcfg
#50647 [WFx]: Short array notation
ID: 50647 User updated by: robert_xp at gmx dot net Reported By: robert_xp at gmx dot net Status: Wont fix Bug Type:Feature/Change Request PHP Version: 5.3.1 New Comment: Grml...Sorry, I didn't saw this before. I read the mailing lists, but I couldn't find a justification why this feature is declined. Most userspace votes were positive, and I added this feature independent from these discussions - maybe open another vote with more parts? Previous Comments: [2010-01-04 12:27:25] ahar...@php.net This has already gone through the RFC process and been declined, per http://wiki.php.net/rfc/shortsyntaxforarrays [2010-01-04 11:46:29] robert_xp at gmx dot net Description: A nice improvement for PHP would be a short hand notation for arrays. You can find more details here: http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- //old: $arr = array(1, 2, array(5 => "foo", 3.14159), 9); //new: $arr = [1, 2, [5 => "foo", 3.14159], 9]; Expected result: In both cases the result of $arr should be the same. Actual result: -- Compile-error -- Edit this bug report at http://bugs.php.net/?id=50647&edit=1
#50652 [WFx]: time call optimization
ID: 50652 User updated by: robert_xp at gmx dot net Reported By: robert_xp at gmx dot net Status: Wont fix Bug Type:Performance problem PHP Version: 5.3.1 New Comment: I'm such an idiot. Sorry, fixed. Previous Comments: [2010-01-04 15:19:35] ras...@php.net Your patch it also reversed. [2010-01-04 15:11:49] robert_xp at gmx dot net Yes, that's right. I think this is the only point, that speaks really against this solution but most scripts should be executed in < 0.x sec and calling time(NULL) many times can be optimized this way. A good improvement could be, applying the patch and change the SAPI handling to check against a config variable if a optimized time handling should be used - with default using the old approach. [2010-01-04 12:25:31] der...@php.net We can't do this, as for longer running scripts the value as returned by time() can change (like once every second). [2010-01-04 12:18:06] robert_xp at gmx dot net Description: Sure, it is not so critical to patch this but you use ever time(NULL) to get the current time in most functions. There is a better way going over the SAPI interface and retrieve a cached value. I published also a patch for all time(NULL/0) calls on http://www.xarg.org/2009/12/php-hacking/ I also hacked the FCGI sapi to get the time value direclty from the webserver - yes it is not supported by default. -- Edit this bug report at http://bugs.php.net/?id=50652&edit=1
#50652 [WFx]: time call optimization
ID: 50652 Updated by: ras...@php.net Reported By: robert_xp at gmx dot net Status: Wont fix Bug Type:Performance problem PHP Version: 5.3.1 New Comment: Your patch it also reversed. Previous Comments: [2010-01-04 15:11:49] robert_xp at gmx dot net Yes, that's right. I think this is the only point, that speaks really against this solution but most scripts should be executed in < 0.x sec and calling time(NULL) many times can be optimized this way. A good improvement could be, applying the patch and change the SAPI handling to check against a config variable if a optimized time handling should be used - with default using the old approach. [2010-01-04 12:25:31] der...@php.net We can't do this, as for longer running scripts the value as returned by time() can change (like once every second). [2010-01-04 12:18:06] robert_xp at gmx dot net Description: Sure, it is not so critical to patch this but you use ever time(NULL) to get the current time in most functions. There is a better way going over the SAPI interface and retrieve a cached value. I published also a patch for all time(NULL/0) calls on http://www.xarg.org/2009/12/php-hacking/ I also hacked the FCGI sapi to get the time value direclty from the webserver - yes it is not supported by default. -- Edit this bug report at http://bugs.php.net/?id=50652&edit=1
#50652 [WFx]: time call optimization
ID: 50652 User updated by: robert_xp at gmx dot net Reported By: robert_xp at gmx dot net Status: Wont fix Bug Type:Performance problem PHP Version: 5.3.1 New Comment: Yes, that's right. I think this is the only point, that speaks really against this solution but most scripts should be executed in < 0.x sec and calling time(NULL) many times can be optimized this way. A good improvement could be, applying the patch and change the SAPI handling to check against a config variable if a optimized time handling should be used - with default using the old approach. Previous Comments: [2010-01-04 12:25:31] der...@php.net We can't do this, as for longer running scripts the value as returned by time() can change (like once every second). [2010-01-04 12:18:06] robert_xp at gmx dot net Description: Sure, it is not so critical to patch this but you use ever time(NULL) to get the current time in most functions. There is a better way going over the SAPI interface and retrieve a cached value. I published also a patch for all time(NULL/0) calls on http://www.xarg.org/2009/12/php-hacking/ I also hacked the FCGI sapi to get the time value direclty from the webserver - yes it is not supported by default. -- Edit this bug report at http://bugs.php.net/?id=50652&edit=1
#50656 [NEW]: Assign constant to var causes syntax error
From: willirl at gmail dot com Operating system: mac os x 10.6 PHP version: 5.3.1 PHP Bug Type: Compile Failure Bug description: Assign constant to var causes syntax error Description: This error is on Mac 10.6 has PHP 5.3.0 which is not shown in version selector. The code causes this error: Parse error: syntax error, unexpected T_VAR in /Users/willirl/Desktop/TEST Files/test.php on line 6 Reproduce code: --- Expected result: No error. $abc set to 25. -- Edit bug report at http://bugs.php.net/?id=50656&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50656&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50656&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50656&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50656&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50656&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50656&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50656&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50656&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50656&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50656&r=support Expected behavior: http://bugs.php.net/fix.php?id=50656&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50656&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50656&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50656&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50656&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50656&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50656&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50656&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50656&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50656&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50656&r=mysqlcfg
#50638 [Bgs]: User Stream $context is Not Populated
ID: 50638
User updated by: cullin dot wible at cullinwible dot com
Reported By: cullin dot wible at cullinwible dot com
Status: Bogus
Bug Type: *General Issues
Operating System: CentOS 5.4 x86_64
PHP Version: 5.3.1
New Comment:
You are correct. This is not a bug. Thanks for the follow-up.
Previous Comments:
[2010-01-03 00:12:45] bj...@php.net
bj...@jessica:~$ php foobar.php
Open Context: resource(5) of type (stream-context)
Fix your parse error and change $context to $this->context
[2010-01-02 23:10:26] cullin dot wible at cullinwible dot com
Description:
When creating a user stream using the streamWrapper format, the
$context variable is NOT set during the stream_open method call.
Reproduce code:
---
class TestStream {
public $context;
public function __construct() {
/* do nothing */
}
public function stream_open($path, $mode, $options, &$opened_path) {
echo "Open Context: ";
var_dump($context);
return(true);
}
}
stream_wrapper_register('test, 'TestStream', 0);
$options = array(
'test' => array(
'option1' => 'option1_value'));
$myContext = stream_context_create($options);
fopen('test://test', 'r', false, $myContext);
Expected result:
the $this->context variable should equal $myContext.
Actual result:
--
The $this->context variable is NULL.
Please NOTE the following:
1. The $context is set on an fread, however, it should be set during
the fopen call.
2. If you look at the PHP-c-code, it appears that the userstream.c
class is attempting to set the $context property just after class
construction and prior to calling stream_open. Also, after modifying the
C-code it appears that the context in the C-code is defined and calls
the Zend add_property_resource function. However, there is clearly a bug
somewhere as the property is still NULL.
--
Edit this bug report at http://bugs.php.net/?id=50638&edit=1
#47412 [Asn->Fbk]: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
ID: 47412 Updated by: paj...@php.net Reported By: tser at deltacontrols dot com -Status: Assigned +Status: Feedback Bug Type: CGI related Operating System: win32 only - Vista PHP Version: 5.2.9RC2 Assigned To: pajoye New Comment: It is called as expected (tested on vista/iis and in the console). If you still experiece this problem, then please provide a detailed way to reproduce: - what are you doing exactly in IIS - values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests (IIS setting) Previous Comments: [2009-12-23 02:27:19] paj...@php.net Will verify this issue once I'm back from vacation. [2009-12-23 02:15:37] liak dot liang at gmail dot com Have the same problem in PHP5.3.0 [2009-04-21 19:30:20] tser at deltacontrols dot com 5.2.10 (April 21) has the same problem. [2009-04-21 17:08:54] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-21 16:38:31] tser at deltacontrols dot com I don't understand the question about parent and child. It is simply the PHP_MSHUTDOWN_FUNCTION not being called (in FastCGI in IIS). You cannot duplicate it in linux because it does not happen in linux. The bug never mention linux. The problem is when using PHP in FastCGI mode using IIS (in Vista, not linux) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47412 -- Edit this bug report at http://bugs.php.net/?id=47412&edit=1
#50654 [Opn->WFx]: Nested heredocs fail
ID: 50654 Updated by: johan...@php.net Reported By: thuejk at gmail dot com -Status: Open +Status: Wont fix Bug Type: Scripting Engine problem Operating System: Debian Linux Unstable PHP Version: 5.2.12 New Comment: This works in 5.3 by using a new parser. Quite risky to change the parser in 5.2. Previous Comments: [2010-01-04 13:09:22] thuejk at gmail dot com Description: Embedding a heredoc inside another heredoc fails to compile on 5.2.12. (The same code successfully compiles on 5.2.4-ubuntu, but running it has the wrong output.) Reproduce code: --- 1); echo << Expected result: 1 Actual result: -- Parse error: syntax error, unexpected $end in /home/thue/test.php on line 11 -- Edit this bug report at http://bugs.php.net/?id=50654&edit=1
#50654 [NEW]: Nested heredocs fail
From: thuejk at gmail dot com Operating system: Debian Linux Unstable PHP version: 5.2.12 PHP Bug Type: Scripting Engine problem Bug description: Nested heredocs fail Description: Embedding a heredoc inside another heredoc fails to compile on 5.2.12. (The same code successfully compiles on 5.2.4-ubuntu, but running it has the wrong output.) Reproduce code: --- 1); echo << Expected result: 1 Actual result: -- Parse error: syntax error, unexpected $end in /home/thue/test.php on line 11 -- Edit bug report at http://bugs.php.net/?id=50654&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50654&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50654&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50654&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50654&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50654&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50654&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50654&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50654&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50654&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50654&r=support Expected behavior: http://bugs.php.net/fix.php?id=50654&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50654&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50654&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50654&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50654&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50654&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50654&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50654&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50654&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50654&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50654&r=mysqlcfg
#49867 [Com]: spl_autoload crashes when called in write function of custom sessionSaveHandler
ID: 49867 Comment by: rik dot meijer at moxio dot com Reported By: nicolas dot lepage at yahoo dot fr Status: No Feedback Bug Type: SPL related Operating System: * PHP Version: 5.3.0 New Comment: I can confirm that the submitted code to reproduce this problem also 'works' on a server without PHP APC installed (used to check). PHP version 5.2.12. Are there any other extensions that could cause this behavior? Loaded extensions: date, libxml, openssl, pcre, zlib, bz2, calendar, ctype, hash, filter, ftp, gettext, gmp, session, iconv, pcntl, readline, Reflection, standard, shmop, SimpleXML, SPL, sockets, exif, tokenizer, xml, cgi- fcgi, bcmath, curl, dba, dbase, dom, gd, htscanner, imap, json, ldap, mbstring, mcrypt, mhash, mysql, mysqli, pdf, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, soap, wddx, xmlreader, xmlrpc, xmlwriter, xsl, zip, Zend Optimizer Previous Comments: [2009-12-05 07:45:22] laruence at yahoo dot com dot cn I can confirm this bug for PHP version 5.2.11 with apc enabled , and I found why: because the request shutdown function of apc is called before the session moudule request shutdown function be called. in which(apc shutdown function), will empty the EG(class_table), (apc_main.c apc_deactivate function), so when the request shutdown function of session was called , the class_table is empty, and why core dump when spl_autoload enabled is also simply , because when zif_spl_autoload was called , it use active_opline->op_code, while the active_opline is NULL then.. you can find more info in:http://www.laruence.com/2009/12/05/1172.html sorry for my poor english [2009-11-20 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-11-13 18:05:48] tomas dot plesek at gmail dot com I can confirm that on stock version of 5.3.0, this bug does NOT occur. [2009-11-12 23:01:35] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-11-12 20:16:21] daedalusvx at gmail dot com I can confirm that this bug occurs on Ubuntu 9.10 with PHP 5.2.10, and does NOT occur on PHP 5.3.0 on OS X through MacPorts. Both have APC installed and enabled. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/49867 -- Edit this bug report at http://bugs.php.net/?id=49867&edit=1
#50650 [Opn]: mysql_matched_rows
ID: 50650 Updated by: u...@php.net Reported By: robert_xp at gmx dot net Status: Open Bug Type:Feature/Change Request PHP Version: 5.3.1 New Comment: What's the point in coding something that can easily be done in the user space and expanding an outdated API? Previous Comments: [2010-01-04 12:02:58] robert_xp at gmx dot net Description: Sometimes, it is necessary to get the number of matches instead of the number of affected rows. Matches means for example in an UPDATE, where no changes were made (0) there could be some matches. There are two possebilities for that case: an own mysqli_info() parser or a new single count query. http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- $res = mysqli_query($h, 'UPDATE something ...'); echo mysql_matched_rows($h); echo mysql_affected_rows($h); Expected result: 1 0 // if there is one row, that has the same value as we want to update Actual result: -- - -- Edit this bug report at http://bugs.php.net/?id=50650&edit=1
#50647 [Opn->WFx]: Short array notation
ID: 50647 Updated by: ahar...@php.net Reported By: robert_xp at gmx dot net -Status: Open +Status: Wont fix Bug Type:Feature/Change Request PHP Version: 5.3.1 New Comment: This has already gone through the RFC process and been declined, per http://wiki.php.net/rfc/shortsyntaxforarrays Previous Comments: [2010-01-04 11:46:29] robert_xp at gmx dot net Description: A nice improvement for PHP would be a short hand notation for arrays. You can find more details here: http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- //old: $arr = array(1, 2, array(5 => "foo", 3.14159), 9); //new: $arr = [1, 2, [5 => "foo", 3.14159], 9]; Expected result: In both cases the result of $arr should be the same. Actual result: -- Compile-error -- Edit this bug report at http://bugs.php.net/?id=50647&edit=1
#50652 [Opn->WFx]: time call optimization
ID: 50652 Updated by: der...@php.net Reported By: robert_xp at gmx dot net -Status: Open +Status: Wont fix Bug Type:Performance problem PHP Version: 5.3.1 New Comment: We can't do this, as for longer running scripts the value as returned by time() can change (like once every second). Previous Comments: [2010-01-04 12:18:06] robert_xp at gmx dot net Description: Sure, it is not so critical to patch this but you use ever time(NULL) to get the current time in most functions. There is a better way going over the SAPI interface and retrieve a cached value. I published also a patch for all time(NULL/0) calls on http://www.xarg.org/2009/12/php-hacking/ I also hacked the FCGI sapi to get the time value direclty from the webserver - yes it is not supported by default. -- Edit this bug report at http://bugs.php.net/?id=50652&edit=1
#50653 [NEW]: str_split sequence handling
From: robert_xp at gmx dot net
Operating system:
PHP version: 5.3.1
PHP Bug Type: Feature/Change Request
Bug description: str_split sequence handling
Description:
str_split is only able to split a string in periodical substrings. I
think, it's a good improvement to allow arrays as a second parameter to
handle sequences. I wrote a patch for that:
http://www.xarg.org/2009/12/php-hacking/
Reproduce code:
---
var_dump(str_split("0123456789abcdefwant to extract this?abcd", array(16,
-4)));
var_dump(str_split("hello how are you?", array(0, 1, 6, 7, 9, -2, -1)));
Expected result:
array(3) {
[0]=>
string(16) "0123456789abcdef"
[1]=>
string(21) "want to extract this?"
[2]=>
string(4) "abcd"
}
array(7) {
[0]=>
string(1) "h"
[1]=>
string(5) "ello "
[2]=>
string(1) "h"
[3]=>
string(2) "ow"
[4]=>
string(7) " are yo"
[5]=>
string(1) "u"
[6]=>
string(1) "?"
}
--
Edit bug report at http://bugs.php.net/?id=50653&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50653&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50653&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50653&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50653&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50653&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50653&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50653&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50653&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50653&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50653&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50653&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50653&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50653&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50653&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50653&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50653&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50653&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50653&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50653&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50653&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50653&r=mysqlcfg
#50027 [Com]: $this becomes a non-object
ID: 50027 Comment by: lukas at twobits dot cz Reported By: phpbugs at colin dot guthr dot ie Status: No Feedback Bug Type: Reproducible crash Operating System: Mandriva Linux (Cooker x86_64) PHP Version: 5.3.1RC2 New Comment: We now have about three weeks of successful operation with zend.enable_gc = Off I assume it is safe to say that this bug indeed is GC related. Previous Comments: [2009-12-16 08:53:15] lukas at twobits dot cz I switched the gc off, will provide feedback in about a week. [2009-12-16 08:11:52] ras...@php.net Does this happen with gc turned off? Try adding: zend.enable_gc = Off to your php.ini file. [2009-12-16 08:09:06] lukas at twobits dot cz We're affected with the same bug - 5.3.1, Fedora Core 8, 32bit, Apache 2.2.6. This happens suddenly after few days of normal operation - then some of the Apache requests end up with $this not defined inside an object instance. Normal operation is resumed after Apache is restarted. We never encountered this problem on 5.3.0 (used for over a month), though I am not saying its not there as lots of our code changed meanwhile as well. [2009-11-12 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-11-11 11:36:32] phpbugs at colin dot guthr dot ie (Hopefully this will not reset the Feedback status). I've tried this on a similar i586 machine and cannot reproduce the problem, this leads me to believe the problem is indeed x86_64 related. I will try and obtain access to another x86_64 machine to reproduce the problem there too. If the bug status changes, please put it back to Feedback. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50027 -- Edit this bug report at http://bugs.php.net/?id=50027&edit=1
#50652 [NEW]: time call optimization
From: robert_xp at gmx dot net Operating system: PHP version: 5.3.1 PHP Bug Type: Performance problem Bug description: time call optimization Description: Sure, it is not so critical to patch this but you use ever time(NULL) to get the current time in most functions. There is a better way going over the SAPI interface and retrieve a cached value. I published also a patch for all time(NULL/0) calls on http://www.xarg.org/2009/12/php-hacking/ I also hacked the FCGI sapi to get the time value direclty from the webserver - yes it is not supported by default. -- Edit bug report at http://bugs.php.net/?id=50652&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50652&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50652&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50652&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50652&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50652&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50652&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50652&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50652&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50652&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50652&r=support Expected behavior: http://bugs.php.net/fix.php?id=50652&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50652&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50652&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50652&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50652&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50652&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50652&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50652&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50652&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50652&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50652&r=mysqlcfg
#50651 [NEW]: Native type cast returns wrong result
From: robert_xp at gmx dot net Operating system: Debain Etch PHP version: 5.3.1 PHP Bug Type: MySQLi related Bug description: Native type cast returns wrong result Description: mysqlnd implements native type casting but returns string for some integer values that seem too big. A fix is also in my mysqlnd patch on http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- - Expected result: any int64 value < INT_MAX should be casted to int as well -- Edit bug report at http://bugs.php.net/?id=50651&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50651&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50651&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50651&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50651&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50651&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50651&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50651&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50651&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50651&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50651&r=support Expected behavior: http://bugs.php.net/fix.php?id=50651&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50651&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50651&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50651&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50651&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50651&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50651&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50651&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50651&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50651&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50651&r=mysqlcfg
#50650 [NEW]: mysql_matched_rows
From: robert_xp at gmx dot net Operating system: PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: mysql_matched_rows Description: Sometimes, it is necessary to get the number of matches instead of the number of affected rows. Matches means for example in an UPDATE, where no changes were made (0) there could be some matches. There are two possebilities for that case: an own mysqli_info() parser or a new single count query. http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- $res = mysqli_query($h, 'UPDATE something ...'); echo mysql_matched_rows($h); echo mysql_affected_rows($h); Expected result: 1 0 // if there is one row, that has the same value as we want to update Actual result: -- - -- Edit bug report at http://bugs.php.net/?id=50650&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50650&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50650&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50650&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50650&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50650&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50650&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50650&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50650&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50650&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50650&r=support Expected behavior: http://bugs.php.net/fix.php?id=50650&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50650&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50650&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50650&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50650&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50650&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50650&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50650&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50650&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50650&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50650&r=mysqlcfg
#50649 [NEW]: negative offsets
From: robert_xp at gmx dot net Operating system: PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: negative offsets Description: I heared somewhere, that string offsets will be removed in future releases of PHP, as of 6.0. I like accessing single characters in a C/C++ like way. If you pass a negative offset to strings, it would be a good improvement to start at the end of the string, like the behavior of substr(). The same is also possible for arrays, but I only focused on string offsets here: http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- $str = "Hello"; echo $str[-2].$str[-1].$str[0]; Expected result: loH Actual result: -- Warnings -- Edit bug report at http://bugs.php.net/?id=50649&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50649&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50649&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50649&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50649&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50649&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50649&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50649&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50649&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50649&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50649&r=support Expected behavior: http://bugs.php.net/fix.php?id=50649&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50649&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50649&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50649&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50649&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50649&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50649&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50649&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50649&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50649&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50649&r=mysqlcfg
#50648 [NEW]: Format for binary numbers
From: robert_xp at gmx dot net Operating system: PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: Format for binary numbers Description: I think it would be a good improvement to have a short form for binary numbers like C# with 0b101010. More information and a patch is provided here: http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- 0b101 Expected result: 5 Actual result: -- compile-error -- Edit bug report at http://bugs.php.net/?id=50648&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50648&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50648&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50648&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50648&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50648&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50648&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50648&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50648&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50648&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50648&r=support Expected behavior: http://bugs.php.net/fix.php?id=50648&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50648&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50648&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50648&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50648&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50648&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50648&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50648&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50648&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50648&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50648&r=mysqlcfg
#50647 [NEW]: Short array notation
From: robert_xp at gmx dot net Operating system: PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: Short array notation Description: A nice improvement for PHP would be a short hand notation for arrays. You can find more details here: http://www.xarg.org/2009/12/php-hacking/ Reproduce code: --- //old: $arr = array(1, 2, array(5 => "foo", 3.14159), 9); //new: $arr = [1, 2, [5 => "foo", 3.14159], 9]; Expected result: In both cases the result of $arr should be the same. Actual result: -- Compile-error -- Edit bug report at http://bugs.php.net/?id=50647&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50647&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50647&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50647&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50647&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50647&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50647&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50647&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50647&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50647&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50647&r=support Expected behavior: http://bugs.php.net/fix.php?id=50647&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50647&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50647&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50647&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50647&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50647&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50647&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50647&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50647&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50647&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50647&r=mysqlcfg
#49262 [Opn->Csd]: PDO MySQL crashes on STRING params
ID: 49262 Updated by: u...@php.net Reported By: grzegorz at heex dot pl -Status: Open +Status: Closed Bug Type: PDO related Operating System: Win XP Sp3 PHP Version: 5.3.0 New Comment: MySQL 6 is not GA, MySQL 6 bug Previous Comments: [2009-12-22 13:02:06] grzegorz at heex dot pl OK, I've downgraded my MySQL to 5.5 and now it's fine. But bug of PHP 5.3 and MySQL 6 is still open. [2009-11-12 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-11-04 17:11:15] u...@php.net If its not crashing with MySQL 5.1, I strongly believe this is a MySQL matter not a PHP problem. Can you try 5.1? Thanks [2009-09-22 18:58:54] grzegorz at heex dot pl It's 6.0.5-alpha-community [2009-09-22 17:00:06] u...@php.net Thanks again, utf8 everywhere. We guessed so. I don't know if its of much relevance but one last question: what version of MySQL 6.0 are you using? .oO( MySQL 6.0 is something I don't like to see here. I wouldn't want to debug a non-GA server, if I had a choice. ) Thanks! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/49262 -- Edit this bug report at http://bugs.php.net/?id=49262&edit=1
#50416 [Asn->Fbk]: PROCEDURE db.myproc can't return a result set in the given context
ID: 50416 Updated by: u...@php.net Reported By: ernesto_vargas at yahoo dot com -Status: Assigned +Status: Feedback Bug Type: MySQL related Operating System: * PHP Version: 5.3, 6 Assigned To: mysql New Comment: This may be a valid error message, http://dev.mysql.com/doc/refman/5.0/en/create-procedure.html . What's the code of the SP? Previous Comments: [2009-12-17 08:23:52] j...@php.net Works with latest PHP 5.2, fails with 5.3+. [2009-12-08 22:44:04] ermesto_vargas at yahoo dot com ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-libdir=lib64 --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic --disable-rpath --without-pear --with-bz2 --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-xpm-dir=/usr --enable-gd-native-ttf --with-t1lib=/usr --without-gdbm --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-pcre-regex=/usr --with-zlib --with-layout=GNU --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --with-kerberos --enable-ucd-snmp-hack --enable-shmop --enable-calendar --without-mime-magic --without-sqlite --with-libxml-dir=/usr --enable-xml --with-system-tzdata --with-mysql --without-gd --disable-dom --disable-dba --without-unixODBC --disable-pdo --disable-xmlreader --disable-xmlwriter --without-sqlite3 --disable-phar --disable-fileinfo --disable-json --without-pspell --disable-wddx --without-curl --disable-posix --disable-sysvmsg --disable-sysvshm --disable-sysvsem Same results here is the result: - Current PHP version: 5.3.2-dev Current MYSQL version: 1.0 Warning: mysql_query(): PROCEDURE test.myproc can't return a result set in the given context in /home/html/sp_test.php on line 14 Invalid query: PROCEDURE test.myproc can't return a result set in the given context Whole query: CALL myproc(); [2009-12-08 21:57:29] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And if that does not work, please provide your configure line. [2009-12-08 20:28:54] ernesto_vargas at yahoo dot com Description: Any call to a mysql stored procedure produces the following error: "PROCEDURE database.store_proc_name can't return a result set in the given context" When calling the stored procedure from mysql cli client do return the results correctly. Tested against MySql 5.0 and 5.1. Work on php-5.2.9 but not on php-5.3.0 or php-5.3.1 Reproduce code: --- DELIMITER $$ CREATE PROCEDURE `myproc`() BEGIN SELECT 'it works!'; END$$ string(9) "it works!" } Actual result: -- Warning: mysql_query(): PROCEDURE test.myproc can't return a result set in the given context in /home/html/sp_test.php on line 11 Invalid query: PROCEDURE test.myproc can't return a result set in the given context Whole query: CALL myproc(); -- Edit this bug report at http://bugs.php.net/?id=50416&edit=1
#48487 [Opn->Csd]: fetch_object calls __set before constructor
ID: 48487
Updated by: u...@php.net
Reported By: joel at purerave dot com
-Status: Open
+Status: Closed
Bug Type: MySQLi related
Operating System: win2k sp4
PHP Version: 5.2.9
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fixed with http://news.php.net/php.cvs/61460
Previous Comments:
[2009-11-06 16:29:19] caferrari at gmail dot com
Help!.. i am having this issue with php 5.2.10 on Ubuntu 9.10 and
Debian 5... and its evil!... my solution:
class Exemplo {
public function __construct($id=0, $nome='', $sigla=''){
if (isset($this->id)) return; //Ugly solution!!! help!
$this->id = $id;
$this->nome = $nome;
$this->sigla= $sigla;
}
}
[2009-08-25 17:14:42] joel at purerave dot com
No response yet?
[2009-06-06 20:33:40] joel at purerave dot com
Description:
mysqli_fetch_object with custom class calls __set() before constructor.
Reproduce code:
---
{$name} = $value;
echo 'setting'.PHP_EOL;
}
}
$sql = "SELECT id FROM test LIMIT 1";
$result = $mysqli->query($sql);
while ($obj = $result->fetch_object('myData', array('data'))) {
}
Expected result:
creating
setting
Actual result:
--
setting
creating
--
Edit this bug report at http://bugs.php.net/?id=48487&edit=1
