#33963 [Asn]: [PATCH] Binding some stored procedure parameters fails
ID: 33963 Updated by: [EMAIL PROTECTED] Reported By: paul dot robinson at groupbc dot com Status: Assigned Bug Type: MSSQL related Operating System: Linux (RHEL 4) PHP Version: 5CVS-2005-08-06 Assigned To: fmk New Comment: As far as I can read, the current code is following Microsofts definitions here: maxlen For variable-length return parameters (when type is SQLCHAR, SQLBINARY, SQLTEXT, or SQLIMAGE), maxlen is the maximum desired byte length for the value parameter returned from a stored procedure. Set maxlen to -1 in any of these cases: For fixed-length return parameters (such as when type is SQLINT4). To pass a NULL fixed-length parameter value (such as when type is SQLINT4) to the stored procedure. For parameters that are not designated as return parameters. Set maxlen to 0 to pass a NULL variable-length parameter value (when type is SQLCHAR, SQLBINARY, SQLTEXT, or SQLIMAGE) to the stored procedure. datalen For variable-length return parameters (where type is SQLCHAR, SQLBINARY, SQLTEXT, or SQLIMAGE), datalen is the actual byte length of the value parameter sent to the stored procedure. The byte length should not count any null terminator. Set datalen to - 1 for non-NULL fixed-length parameters (such as when type is SQLINT4). Set datalen to 0 to pass a NULL parameter value (fixed or variable length) to the stored procedure I think this should be fixed in FreeTDS Previous Comments: [2005-08-06 01:31:45] [EMAIL PROTECTED] Frank, check this out too.. [2005-08-05 16:52:00] paul dot robinson at groupbc dot com Patch against php_mssql.c CVS version 1.149 can be found here: http://cobweb.businesscollaborator.com/pdr/33963.patch The values of maxlen and datalen set here have been verified to work with FreeTDS 0.63 and the latest CVS code as of 5/8/2005. [2005-08-02 19:13:45] [EMAIL PROTECTED] Provide patches in unified diff format (diff -u) and against PHP CVS HEAD (we're not likely to release any 5.0.x versions anymore). Put the diffs somewhere were people can download it and put the URLs here. [2005-08-02 18:51:03] paul dot robinson at groupbc dot com Patches suggested are against Snapshot: php5-STABLE-200508021038.tar.gz Although I haven't actually built an example using that snapshot today I have looked at the code which since it is unchanged would seem to exhibit the same problem. [2005-08-02 18:34:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip 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/33963 -- Edit this bug report at http://bugs.php.net/?id=33963&edit=1
#33965 [Asn->Csd]: [PATCH] NULL valued output parameter from stored procedures contain corrupt data
ID: 33965 Updated by: [EMAIL PROTECTED] Reported By: paul dot robinson at groupbc dot com -Status: Assigned +Status: Closed Bug Type: MSSQL related Operating System: Linux (RHEL 4) PHP Version: 5CVS-2005-08-06 Assigned To: fmk New Comment: This bug has been fixed in CVS. 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: [2005-08-06 01:30:57] [EMAIL PROTECTED] Frank, can you check this out? [2005-08-05 16:57:19] paul dot robinson at groupbc dot com Patch against php_mssql.c CVS version 1.149 can be found here: http://cobweb.businesscollaborator.com/pdr/33965.patch Rationale behind the patch was discussed here: http://lists.ibiblio.org/pipermail/freetds/2005q3/018851.html This has been verified to work with FreeTDS releases _after_ 0.63. Without this patch output parameters that should be null will simply read random data. [2005-08-02 19:12:53] [EMAIL PROTECTED] Provide patches in unified diff format (diff -u) and against PHP CVS HEAD (we're not likely to release any 5.0.x versions anymore). Put the diffs somewhere were people can download it and put the URLs here. [2005-08-02 18:50:33] paul dot robinson at groupbc dot com Patches suggested are against Snapshot: php5-STABLE-200508021038.tar.gz Although I haven't actually built an example using that snapshot today I have looked at the code which since it is unchanged would seem to exhibit the same problem. [2005-08-02 18:34:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip 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/33965 -- Edit this bug report at http://bugs.php.net/?id=33965&edit=1
#32531 [Asn->Csd]: Sybase extension contains aliases to mssql functions that can never be used
ID: 32531
Updated by: [EMAIL PROTECTED]
Reported By: daniel dot beet at accuratesoftware dot com
-Status: Assigned
+Status: Closed
Bug Type: Sybase-ct (ctlib) related
Operating System: Windows
PHP Version: 5.0.4, 4.3.11
Assigned To: fmk
New Comment:
This bug has been fixed in CVS.
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:
[2005-08-06 01:36:32] [EMAIL PROTECTED]
Frank, do you have any opinions about this?
(just make ext/mssql shared ext in windows maybe? :)
[2005-04-20 16:38:47] frodelangvik at hotmail dot com
Removed the current ALIAS handling and insert the following, and the
compile the file again.
#ifdef PHP_WIN32
function_entry sybase_functions[] = {
PHP_FE(sybase_connect, NULL)
PHP_FE(sybase_pconnect, NULL)
PHP_FE(sybase_close, NULL)
PHP_FE(sybase_select_db, NULL)
PHP_FE(sybase_query, NULL)
PHP_FE(sybase_unbuffered_query, NULL)
PHP_FE(sybase_free_result, NULL)
PHP_FE(sybase_get_last_message, NULL)
PHP_FE(sybase_num_rows, NULL)
PHP_FE(sybase_num_fields, NULL)
PHP_FE(sybase_fetch_row, NULL)
PHP_FE(sybase_fetch_array, NULL)
PHP_FE(sybase_fetch_assoc, NULL)
PHP_FE(sybase_fetch_object, NULL)
PHP_FE(sybase_data_seek, NULL)
PHP_FE(sybase_fetch_field, NULL)
PHP_FE(sybase_field_seek, NULL)
PHP_FE(sybase_result, NULL)
PHP_FE(sybase_affected_rows, NULL)
PHP_FE(sybase_min_client_severity, NULL)
PHP_FE(sybase_min_server_severity, NULL)
PHP_FE(sybase_set_message_handler, NULL)
PHP_FE(sybase_deadlock_retry_count, NULL)
{NULL, NULL, NULL}
};
#else
function_entry sybase_functions[] = {
PHP_FE(sybase_connect, NULL)
PHP_FE(sybase_pconnect, NULL)
PHP_FE(sybase_close, NULL)
PHP_FE(sybase_select_db, NULL)
PHP_FE(sybase_query, NULL)
PHP_FE(sybase_unbuffered_query, NULL)
PHP_FE(sybase_free_result, NULL)
PHP_FE(sybase_get_last_message, NULL)
PHP_FE(sybase_num_rows, NULL)
PHP_FE(sybase_num_fields, NULL)
PHP_FE(sybase_fetch_row, NULL)
PHP_FE(sybase_fetch_array, NULL)
PHP_FE(sybase_fetch_assoc, NULL)
PHP_FE(sybase_fetch_object, NULL)
PHP_FE(sybase_data_seek, NULL)
PHP_FE(sybase_fetch_field, NULL)
PHP_FE(sybase_field_seek, NULL)
PHP_FE(sybase_result, NULL)
PHP_FE(sybase_affected_rows, NULL)
PHP_FE(sybase_min_client_severity, NULL)
PHP_FE(sybase_min_server_severity, NULL)
PHP_FE(sybase_set_message_handler, NULL)
PHP_FE(sybase_deadlock_retry_count, NULL)
PHP_FALIAS(mssql_connect, sybase_connect, NULL)
PHP_FALIAS(mssql_pconnect, sybase_pconnect, NULL)
PHP_FALIAS(mssql_close, sybase_close, NULL)
PHP_FALIAS(mssql_select_db, sybase_select_db, NULL)
PHP_FALIAS(mssql_query, sybase_query, NULL)
PHP_FALIAS(mssql_unbuffered_query, sybase_unbuffered_query,
NULL)
PHP_FALIAS(mssql_free_result, sybase_free_result, NULL)
PHP_FALIAS(mssql_get_last_message, sybase_get_last_message,
NULL)
PHP_FALIAS(mssql_num_rows, sybase_num_rows, NULL)
PHP_FALIAS(mssql_num_fields, sybase_num_fields, NULL)
PHP_FALIAS(mssql_fetch_row, sybase_fetch_row, NULL)
PHP_FALIAS(mssql_fetch_array, sybase_fetch_array, NULL)
PHP_FALIAS(mssql_fetch_assoc, sybase_fetch_assoc, NULL)
PHP_FALIAS(mssql_fetch_object, sybase_fetch_object, NULL)
PHP_FALIAS(mssql_data_seek, sybase_data_seek, NULL)
PHP_FALIAS(mssql_fetch_field, sybase_fetch_field, NULL)
PHP_FALIAS(mssql_field_seek, sybase_field_seek, NULL)
PHP_FALIAS(mssql_result, sybase_result, NULL)
PHP_FALIAS(mssql_affected_rows, sybase_affected_rows, NULL)
PHP_FALIAS(mssql_min_client_severity,
sybase_min_client_severity,
NULL)
PHP_FALIAS(mssql_min_server_severity,
sybase_min_server_severity,
NULL)
#34016 [NEW]: GD Library DLL is missing
From: stochnagara at hotmail dot com Operating system: windows xp PHP version: 5CVS-2005-08-06 (dev) PHP Bug Type: GD related Bug description: GD Library DLL is missing Description: The binary distribution for Windows from 6.August comes without php_gd2.dll. Reproduce code: --- no Expected result: no Actual result: -- no -- Edit bug report at http://bugs.php.net/?id=34016&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34016&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34016&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34016&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34016&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34016&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34016&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34016&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34016&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34016&r=support Expected behavior: http://bugs.php.net/fix.php?id=34016&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34016&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34016&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34016&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34016&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34016&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34016&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34016&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34016&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34016&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34016&r=mysqlcfg
#34008 [Csd->Opn]: Make file error
ID: 34008 User updated by: ljanda at checkstop dot com Reported By: ljanda at checkstop dot com -Status: Closed +Status: Open Bug Type: *Compile Issues Operating System: SCO 5.05 PHP Version: 4.4.0 New Comment: The problem still exists. That line should have a tab. I can fix that but the stopping point is the "make install". make install OVERALL_TARGET += /u/leroy/php4-STABLE-200508060247/ext/informix/ifx.c sh: OVERALL_TARGET: not found *** Error code 1 (bu21) # Previous Comments: [2005-08-05 22:28:47] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. Sometimes simple things cause big problems. It was actually just one missing empty line in the beginning of ext/informix/Makefile.frag [2005-08-05 20:48:46] ljanda at checkstop dot com OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c Also the above is supposed to be a directory?? failing in make install [2005-08-05 20:47:13] ljanda at checkstop dot com Have no access to other servers [2005-08-05 19:51:22] [EMAIL PROTECTED] Are you able to reproduce on non-SCO server? [2005-08-05 15:37:14] ljanda at checkstop dot com Description: Simple problem in configure: ./configure --without-mysql --with-informix --with-apache=../apache_1.3.19 --ena ble-shared --enable-track-vars Adding the Informix puts a line into make file without tab (\t) and therefore the make fails. Looked and makefile and sure enough, the line was left justified, put the tab in and got it to work. Reproduce code: --- install-cli: $(SAPI_CLI_PATH) @echo "Installing PHP CLI binary:$(INSTALL_ROOT)$(bindir)/" @$(INSTALL_CLI) @echo "Installing PHP CLI man page: $(INSTALL_ROOT)$(mandir)/man1/" @$(mkinstalldirs) $(INSTALL_ROOT)$(mandir)/man1 @$(INSTALL_DATA) sapi/cli/php.1 $(INSTALL_ROOT)$(mandir)/man1/php.1 /*** this line needs a tab OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c /u/leroy/php- Expected result: make error -- Edit this bug report at http://bugs.php.net/?id=34008&edit=1
#33770 [Opn->Fbk]: https:// or ftps:// do not work with both --with-openssl and --with-curlwrappers
ID: 33770 Updated by: [EMAIL PROTECTED] Reported By: subscription at nazarenko dot net -Status: Open +Status: Feedback Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 PHP Version: 5CVS-2005-07-19 New Comment: I'm using these libs: openssl 0.9.7f curl 7.13.1 So try upgrade those. (you do have the 64bit versions of those installed?) Previous Comments: [2005-08-02 19:33:15] subscription at nazarenko dot net Tried php5-200508021630 CVS snapshot. https works: ./configure --disable-all --disable-cgi --with-openssl --with-curl https does not work: ./configure --disable-all --disable-cgi --with-openssl --with-curl --with-curlwrappers My machine is x64 Linux (SuSE 9.3) OpenSSL libraries: openssl-devel-0.9.7e-3 CURL libraries: curl-devel-7.13.0-5 [2005-08-02 07:57:46] [EMAIL PROTECTED] I can't reproduce this, with having both of those configure options enabled the same time. Please try latest CVS snapshot. [2005-07-20 00:48:35] subscription at nazarenko dot net Thank you for a speedy response. Indeed, with the minimal configure, it started working again. After 1 hour of mixing and matching the modules I found the culprit. It is: curl-7.13.0 libraries compiled in with the following parameters: --with-curl --with-curlwrappers Actually, without "--with-curlwrappers" it works fine. Tested both for 5.0.4 and 5CVS [2005-07-19 21:32:47] [EMAIL PROTECTED] Works fine for me under FC4 x86_64smp. Try with this configure line: ./configure --disable-all --disable-cgi --with-openssl And use sapi/cli/php to run your script. [2005-07-19 21:23:47] [EMAIL PROTECTED] subscription at nazarenko dot net: "Tried the latest snapshot as advised. Same effect as before, the problem persists. Test script: https://host2/";)); ?> Both "host1" and "host2" are on the same subnet. " (do NOT add any huge outputs of anything unless asked for!) 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/33770 -- Edit this bug report at http://bugs.php.net/?id=33770&edit=1
#32531 [Opn->Asn]: Sybase extension contains aliases to mssql functions that can never be used
ID: 32531
Updated by: [EMAIL PROTECTED]
Reported By: daniel dot beet at accuratesoftware dot com
-Status: Open
+Status: Assigned
Bug Type: Sybase-ct (ctlib) related
Operating System: Windows
PHP Version: 5.0.4, 4.3.11
-Assigned To:
+Assigned To: fmk
New Comment:
Frank, do you have any opinions about this?
(just make ext/mssql shared ext in windows maybe? :)
Previous Comments:
[2005-04-20 16:38:47] frodelangvik at hotmail dot com
Removed the current ALIAS handling and insert the following, and the
compile the file again.
#ifdef PHP_WIN32
function_entry sybase_functions[] = {
PHP_FE(sybase_connect, NULL)
PHP_FE(sybase_pconnect, NULL)
PHP_FE(sybase_close, NULL)
PHP_FE(sybase_select_db, NULL)
PHP_FE(sybase_query, NULL)
PHP_FE(sybase_unbuffered_query, NULL)
PHP_FE(sybase_free_result, NULL)
PHP_FE(sybase_get_last_message, NULL)
PHP_FE(sybase_num_rows, NULL)
PHP_FE(sybase_num_fields, NULL)
PHP_FE(sybase_fetch_row, NULL)
PHP_FE(sybase_fetch_array, NULL)
PHP_FE(sybase_fetch_assoc, NULL)
PHP_FE(sybase_fetch_object, NULL)
PHP_FE(sybase_data_seek, NULL)
PHP_FE(sybase_fetch_field, NULL)
PHP_FE(sybase_field_seek, NULL)
PHP_FE(sybase_result, NULL)
PHP_FE(sybase_affected_rows, NULL)
PHP_FE(sybase_min_client_severity, NULL)
PHP_FE(sybase_min_server_severity, NULL)
PHP_FE(sybase_set_message_handler, NULL)
PHP_FE(sybase_deadlock_retry_count, NULL)
{NULL, NULL, NULL}
};
#else
function_entry sybase_functions[] = {
PHP_FE(sybase_connect, NULL)
PHP_FE(sybase_pconnect, NULL)
PHP_FE(sybase_close, NULL)
PHP_FE(sybase_select_db, NULL)
PHP_FE(sybase_query, NULL)
PHP_FE(sybase_unbuffered_query, NULL)
PHP_FE(sybase_free_result, NULL)
PHP_FE(sybase_get_last_message, NULL)
PHP_FE(sybase_num_rows, NULL)
PHP_FE(sybase_num_fields, NULL)
PHP_FE(sybase_fetch_row, NULL)
PHP_FE(sybase_fetch_array, NULL)
PHP_FE(sybase_fetch_assoc, NULL)
PHP_FE(sybase_fetch_object, NULL)
PHP_FE(sybase_data_seek, NULL)
PHP_FE(sybase_fetch_field, NULL)
PHP_FE(sybase_field_seek, NULL)
PHP_FE(sybase_result, NULL)
PHP_FE(sybase_affected_rows, NULL)
PHP_FE(sybase_min_client_severity, NULL)
PHP_FE(sybase_min_server_severity, NULL)
PHP_FE(sybase_set_message_handler, NULL)
PHP_FE(sybase_deadlock_retry_count, NULL)
PHP_FALIAS(mssql_connect, sybase_connect, NULL)
PHP_FALIAS(mssql_pconnect, sybase_pconnect, NULL)
PHP_FALIAS(mssql_close, sybase_close, NULL)
PHP_FALIAS(mssql_select_db, sybase_select_db, NULL)
PHP_FALIAS(mssql_query, sybase_query, NULL)
PHP_FALIAS(mssql_unbuffered_query, sybase_unbuffered_query,
NULL)
PHP_FALIAS(mssql_free_result, sybase_free_result, NULL)
PHP_FALIAS(mssql_get_last_message, sybase_get_last_message,
NULL)
PHP_FALIAS(mssql_num_rows, sybase_num_rows, NULL)
PHP_FALIAS(mssql_num_fields, sybase_num_fields, NULL)
PHP_FALIAS(mssql_fetch_row, sybase_fetch_row, NULL)
PHP_FALIAS(mssql_fetch_array, sybase_fetch_array, NULL)
PHP_FALIAS(mssql_fetch_assoc, sybase_fetch_assoc, NULL)
PHP_FALIAS(mssql_fetch_object, sybase_fetch_object, NULL)
PHP_FALIAS(mssql_data_seek, sybase_data_seek, NULL)
PHP_FALIAS(mssql_fetch_field, sybase_fetch_field, NULL)
PHP_FALIAS(mssql_field_seek, sybase_field_seek, NULL)
PHP_FALIAS(mssql_result, sybase_result, NULL)
PHP_FALIAS(mssql_affected_rows, sybase_affected_rows, NULL)
PHP_FALIAS(mssql_min_client_severity,
sybase_min_client_severity,
NULL)
PHP_FALIAS(mssql_min_server_severity,
sybase_min_server_severity,
NULL)
PHP_FALIAS(mssql_set_message_handler,
sybase_set_message_handler,
NULL)
PHP_FALIAS(mssql_deadlock_retry_count,
sybase_deadlock_retry_count,
NULL)
{NULL, NULL, NULL}
};
#endif
Best regards,
Frode Langvik
[2005-04-0
#30257 [Opn->Asn]: Unexpected result of xml_get_current_byte_index and xml_get_current_column_numb
ID: 30257
Updated by: [EMAIL PROTECTED]
Reported By: christoffer at natlikan dot se
-Status: Open
+Status: Assigned
Bug Type: XML related
Operating System: *
PHP Version: 5CVS-2005-02-02
-Assigned To:
+Assigned To: rrichards
New Comment:
Rob, you had some nice explanation about this, iirc?
IIRC, this is libxml issue, not something we can fix?
Previous Comments:
[2005-08-04 11:44:37] [EMAIL PROTECTED]
It's so weird that it should be rather fixed than documented:
All functions point to the end of a tag instead of beginning. (it can
be documented)
xml_get_current_byte_index() and xml_get_current_column_number() behave
unpredictable (it should be fixed):
CN=42, BI=4
CN=42, BI=5
CN=42, BI=4
CN=39, BI=40
Another problem is with attribute values and whitespace. They are not
counted to CN (it should be fixed):
CN=41, BI=45
CN=41, BI=46
CN=41, BI=46
CN=41, BI=48
Such a weird behavior is nearly undocumentable and unusable for sure.
[2005-08-01 00:37:06] [EMAIL PROTECTED]
This difference is caused by the fact that in PHP5 we use libxml
instead of expat by default.
To get the expat behaviour, you can always compile PHP with
--with-expat-dir=/path/to/expat
This change in behaviour needs to be documented though.
[2004-09-30 01:27:16] olivier at samalyse dot com
I'm experiencing similar troubles with xml_get_current_byte_index().
But I don't agree with the expected result christoffer proposes.
Actually, in php4 xml_get_current_byte_index() behaves perfectly to me.
Using the test code below with php version 4.3.4 produces :
ElementOpen - Row: 2 Col: 0 BIndex: 44
ElementOpen - Row: 4 Col: 1 BIndex: 61
ElementOpen - Row: 5 Col: 2 BIndex: 67
ElementClose - Row: 5 Col: 8 BIndex: 73
ElementClose - Row: 6 Col: 1 BIndex: 79
ElementClose - Row: 7 Col: 0 BIndex: 84
Byte Index 44 points at the beginning of the tag :
^
That is fine.
Now, if you omit the xml declaration '', using php5, you will obtain :
ElementOpen - Row: 1 Col: 5 BIndex: 8
ElementOpen - Row: 3 Col: 8 BIndex: 19
ElementOpen - Row: 4 Col: 11 BIndex: 25
ElementClose - Row: 4 Col: 15 BIndex: 33
ElementClose - Row: 5 Col: 18 BIndex: 39
ElementClose - Row: 6 Col: 21 BIndex: 44
Byte index 8 does not point at the beginning of the tag anymore, but at
its end :
^
In my particular case (XML indexing/marshalling) that's far less
usable. Some may consider that's no bug, but it breaks backward
compatibility with php4.
Now, if you let the xml declaration in place, this function does not
produce anything relevant anymore. As Christoffer reports, parsing this
xml document when it includes '' will produce :
ElementOpen - Row: 2 Col: 5 BIndex: 11
ElementOpen - Row: 4 Col: 8 BIndex: 22
ElementOpen - Row: 5 Col: 11 BIndex: 28
ElementClose - Row: 5 Col: 15 BIndex: 36
ElementClose - Row: 6 Col: 18 BIndex: 42
ElementClose - Row: 7 Col: 21 BIndex: 47
In this later case, what seems to happen is that the xml declaration
byte length is badly evaluated. If you add to this the fact that the
returned byte index points at the end of the tag (php5) instead of the
beginning of the tag (php4), it really starts to look like random
output...
[2004-09-27 20:36:13] christoffer at natlikan dot se
Description:
xml_get_current_byte_index and xml_get_current_column_number returns
unexpected values when the XML contains a XML declaration. Using
php5.0-win32-200409270830 and Apache/1.3.31.
Reproduce code:
---
");
}
function elementClose($parser, $elementName) {
echo("ElementClose - Row: " .
xml_get_current_line_number($parser) .
" Col: " . xml_get_current_column_number($parser) .
" BIndex: " . xml_get_current_byte_index($parser) .
"");
}
$parser = xml_parser_create();
xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, false);
xml_set_element_handler($parser, "elementOpen", "elementClose");
$xml =
"\n" .
"\n" .
"\ttest\n" .
"\t\n" .
"\t\tfoo\n" .
"\t\n" .
"";
xml_parse($parser, $xml);
xml_parser_free($parser);
?>
Expected result:
ElementOpen - Row: 2 Col: 10 BIndex: 52
ElementOpen - Row: 4 Col: 8 BIndex: 63
ElementOpen - Row: 5 Col: 11 BIndex: 69
ElementClose - Row: 5 Col: 9 BIndex: 73
ElementClose - Row: 6 Col: 2 BIndex: 79
ElementClose - Row: 7 Col: 1 BIndex: 85
Actual result:
--
Ele
#33963 [Opn->Asn]: [PATCH] Binding some stored procedure parameters fails
ID: 33963
Updated by: [EMAIL PROTECTED]
-Summary: Binding some stored procedure parameters fails
Reported By: paul dot robinson at groupbc dot com
-Status: Open
+Status: Assigned
Bug Type: MSSQL related
Operating System: Linux (RHEL 4)
-PHP Version: 5.0.4
+PHP Version: 5CVS-2005-08-06
-Assigned To:
+Assigned To: fmk
New Comment:
Frank, check this out too..
Previous Comments:
[2005-08-05 16:52:00] paul dot robinson at groupbc dot com
Patch against php_mssql.c CVS version 1.149 can be found here:
http://cobweb.businesscollaborator.com/pdr/33963.patch
The values of maxlen and datalen set here have been verified to work
with FreeTDS 0.63 and the latest CVS code as of 5/8/2005.
[2005-08-02 19:13:45] [EMAIL PROTECTED]
Provide patches in unified diff format (diff -u) and against PHP CVS
HEAD (we're not likely to release any 5.0.x versions anymore). Put the
diffs somewhere were people can download it and put the URLs here.
[2005-08-02 18:51:03] paul dot robinson at groupbc dot com
Patches suggested are against Snapshot:
php5-STABLE-200508021038.tar.gz
Although I haven't actually built an example using that snapshot today
I have looked at the code which since it is unchanged would seem to
exhibit the same problem.
[2005-08-02 18:34:32] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-02 13:39:23] paul dot robinson at groupbc dot com
Description:
Using FreeTDS 0.63 (latest stable release), calling mssql_bind can fail
due to the restrictions placed on parameters by the dbrpcparam function
from FreeTDS.
One specific example is an input parameter must have maxlen==-1. With
the code as is in PHP 5.0.4 a NULL valued variable length type input
parameter will always have maxlen==0 thereby always failing.
Diff below shows changes to ext/mssql/php_mssql.c that address this
parameter mismatch.
2025,2026c2025,2029
< maxlen=0;
< datalen=0;
---
> datalen = 0;
> if (is_output)
> maxlen = -1;
> else
> maxlen = -1;
2030d2032
< datalen=Z_STRLEN_PP(var);
2031a2034,2046
>
> if (is_output) {
> if ((maxlen > 0 ) && (maxlen < 256))
> datalen = maxlen;
> else {
> maxlen = 255;
> datalen = 255;
> }
> }
> else {
> maxlen = -1;
> datalen=Z_STRLEN_PP(var);
> }
Reproduce code:
---
mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR);
or
mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR, false, true,
57);
Expected result:
Sucessfully bind input variable.
Actual result:
--
"Unable to set parameter"
i.e. FAIL is returned by the call to dbrpcparam in
PHP_FUNCTION(mssql_bind).
--
Edit this bug report at http://bugs.php.net/?id=33963&edit=1
#33965 [Opn->Asn]: [PATCH] NULL valued output parameter from stored procedures contain corrupt data
ID: 33965
Updated by: [EMAIL PROTECTED]
-Summary: NULL valued output parameters from stored procedures
contain corrupt data
Reported By: paul dot robinson at groupbc dot com
-Status: Open
+Status: Assigned
Bug Type: MSSQL related
Operating System: Linux (RHEL 4)
-PHP Version: 5.0.4
+PHP Version: 5CVS-2005-08-06
-Assigned To:
+Assigned To: fmk
New Comment:
Frank, can you check this out?
Previous Comments:
[2005-08-05 16:57:19] paul dot robinson at groupbc dot com
Patch against php_mssql.c CVS version 1.149 can be found here:
http://cobweb.businesscollaborator.com/pdr/33965.patch
Rationale behind the patch was discussed here:
http://lists.ibiblio.org/pipermail/freetds/2005q3/018851.html
This has been verified to work with FreeTDS releases _after_ 0.63.
Without this patch output parameters that should be null will simply
read random data.
[2005-08-02 19:12:53] [EMAIL PROTECTED]
Provide patches in unified diff format (diff -u) and against PHP CVS
HEAD (we're not likely to release any 5.0.x versions anymore). Put the
diffs somewhere were people can download it and put the URLs here.
[2005-08-02 18:50:33] paul dot robinson at groupbc dot com
Patches suggested are against Snapshot:
php5-STABLE-200508021038.tar.gz
Although I haven't actually built an example using that snapshot today
I have looked at the code which since it is unchanged would seem to
exhibit the same problem.
[2005-08-02 18:34:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-02 14:01:38] paul dot robinson at groupbc dot com
Description:
MS SQL Server 2000, FreeTDS 0.63
Output parameters from a stored procedure call contain corrupt data
when the result should be NULL. Its particularly noticable for variable
length strings as output looks as though it just reads from a random
pointer until it find a \0 !
No test is done on whether the output is NULL or not.
Diff below shows proposed change to fix this.
NOTE: This calls a function dbretisnull that is not currently
implemented in the FreeTDS package but has been submitted as a proposed
change.
19c19
< /* $Id: php_mssql.c,v 1.137.2.9 2005/04/12 17:46:06 fmk Exp $ */
---
> /* $Id: php_mssql.c,v 1.137.2.8 2005/02/25 23:25:33 fmk Exp $ */
324,326d323
< #ifndef HAVE_FREETDS
< dbwinexit();
< #else
328d324
< #endif
978c974
< int i, num_rets, type;
---
> int i, num_rets, type, is_null;
992,1019c988,1022
< switch (type) {
< case SQLBIT:
< case SQLINT1:
< case SQLINT2:
< case SQLINT4:
<
convert_to_long_ex(&bind->zval);
< /* FIXME this
works only on little endian machine !!! */
<
Z_LVAL_P(bind->zval) = *((int *)(dbretdata(mssql_ptr->link,i)));
< break;
<
< case SQLFLT4:
< case SQLFLT8:
< case SQLFLTN:
< case SQLMONEY4:
< case SQLMONEY:
< case SQLMONEYN:
<
convert_to_double_ex(&bind->zval);
<
Z_DVAL_P(bind->zval) = *((double *)(dbretdata(mssql_ptr->link,i)));
< break;
<
< case SQLCHAR:
< case SQLVARCHAR:
< case SQLTEXT:
<
convert_to_string_ex(&bind->zval);
<
Z_STRLEN_P(bind->zval) = dbretlen(mssql_ptr->link,i);
<
Z_STRVAL_P(bind->zval) =
estrndup(dbretdata(mssql_ptr->link,i),Z_STRLEN_P(bind->zval));
< break;
<
#34015 [Csd]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com Status: Closed Bug Type: mbstring related Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: One more thing: If your php.ini file does not have extension_dir set properly, the default one will be used instead. Previous Comments: [2005-08-06 00:58:46] [EMAIL PROTECTED] You should read it more carefully: [Which php.ini is used] --- "make test" uses the same php.ini file as it would once installed. The tests have been written to be independent of that php.ini file, so if you find a test that is affected by a setting, please report this, so we can address the issue. And I fixed that test. Also, the path in question is 'extension_dir'.. Now leave this report closed, the problem IS solved already. [2005-08-06 00:47:39] RVaughn at pheedo dot com Those bad paths do not appear in my /etc/php.ini system file. In the original report I show the include path: ; UNIX: "/path1:/path2" include_path=".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Why isn't the test script using that? Thanks! [2005-08-06 00:46:21] RVaughn at pheedo dot com Wait, what's intentional? That the README file is misleading (or wrong) in saying the system php.ini file is used? Or that the system ini file is used, which means the README file ought to be updated? Sorry, really confused now... thanks! Cheers, Rob [2005-08-06 00:44:28] RVaughn at pheedo dot com Thanks Sniper, for a real answer rather than a rote one. Is there any way to get more info on this bug? Namely, is it a problem with the test script or with PHP or both? I don't want to have to pull a whole new distribution of PHP 4.4 down and build it from scratch; we're trying to run a business. Thanks! Cheers, Rob [2005-08-06 00:41:59] [EMAIL PROTECTED] Hehe..don't trust everything you read. :) The tests definately use your php.ini. It's intentional and will not be changed. 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/34015 -- Edit this bug report at http://bugs.php.net/?id=34015&edit=1
#34015 [Opn->Csd]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Closed Bug Type: mbstring related Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: You should read it more carefully: [Which php.ini is used] --- "make test" uses the same php.ini file as it would once installed. The tests have been written to be independent of that php.ini file, so if you find a test that is affected by a setting, please report this, so we can address the issue. And I fixed that test. Also, the path in question is 'extension_dir'.. Now leave this report closed, the problem IS solved already. Previous Comments: [2005-08-06 00:47:39] RVaughn at pheedo dot com Those bad paths do not appear in my /etc/php.ini system file. In the original report I show the include path: ; UNIX: "/path1:/path2" include_path=".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Why isn't the test script using that? Thanks! [2005-08-06 00:46:21] RVaughn at pheedo dot com Wait, what's intentional? That the README file is misleading (or wrong) in saying the system php.ini file is used? Or that the system ini file is used, which means the README file ought to be updated? Sorry, really confused now... thanks! Cheers, Rob [2005-08-06 00:44:28] RVaughn at pheedo dot com Thanks Sniper, for a real answer rather than a rote one. Is there any way to get more info on this bug? Namely, is it a problem with the test script or with PHP or both? I don't want to have to pull a whole new distribution of PHP 4.4 down and build it from scratch; we're trying to run a business. Thanks! Cheers, Rob [2005-08-06 00:41:59] [EMAIL PROTECTED] Hehe..don't trust everything you read. :) The tests definately use your php.ini. It's intentional and will not be changed. [2005-08-06 00:39:22] RVaughn at pheedo dot com As said, these do *not* appear in my php.ini file. You're just making an assumption about that. The paths do *not* appear anywhere in the php.ini (the tests are supposed to ignore the /etc/php.ini file and use the one in the source code anyway, according to README.TESTING) and those weird paths do not appear anywhere on my system nor in the source code. The conclusions you've jumped to are mistaken. 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/34015 -- Edit this bug report at http://bugs.php.net/?id=34015&edit=1
#34015 [Opn]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com Status: Open Bug Type: mbstring related Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: Those bad paths do not appear in my /etc/php.ini system file. In the original report I show the include path: ; UNIX: "/path1:/path2" include_path=".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Why isn't the test script using that? Thanks! Previous Comments: [2005-08-06 00:46:21] RVaughn at pheedo dot com Wait, what's intentional? That the README file is misleading (or wrong) in saying the system php.ini file is used? Or that the system ini file is used, which means the README file ought to be updated? Sorry, really confused now... thanks! Cheers, Rob [2005-08-06 00:44:28] RVaughn at pheedo dot com Thanks Sniper, for a real answer rather than a rote one. Is there any way to get more info on this bug? Namely, is it a problem with the test script or with PHP or both? I don't want to have to pull a whole new distribution of PHP 4.4 down and build it from scratch; we're trying to run a business. Thanks! Cheers, Rob [2005-08-06 00:41:59] [EMAIL PROTECTED] Hehe..don't trust everything you read. :) The tests definately use your php.ini. It's intentional and will not be changed. [2005-08-06 00:39:22] RVaughn at pheedo dot com As said, these do *not* appear in my php.ini file. You're just making an assumption about that. The paths do *not* appear anywhere in the php.ini (the tests are supposed to ignore the /etc/php.ini file and use the one in the source code anyway, according to README.TESTING) and those weird paths do not appear anywhere on my system nor in the source code. The conclusions you've jumped to are mistaken. Thanks. [2005-08-05 22:39:56] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. 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/34015 -- Edit this bug report at http://bugs.php.net/?id=34015&edit=1
#34015 [Opn]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com Status: Open Bug Type: mbstring related Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: Wait, what's intentional? That the README file is misleading (or wrong) in saying the system php.ini file is used? Or that the system ini file is used, which means the README file ought to be updated? Sorry, really confused now... thanks! Cheers, Rob Previous Comments: [2005-08-06 00:44:28] RVaughn at pheedo dot com Thanks Sniper, for a real answer rather than a rote one. Is there any way to get more info on this bug? Namely, is it a problem with the test script or with PHP or both? I don't want to have to pull a whole new distribution of PHP 4.4 down and build it from scratch; we're trying to run a business. Thanks! Cheers, Rob [2005-08-06 00:41:59] [EMAIL PROTECTED] Hehe..don't trust everything you read. :) The tests definately use your php.ini. It's intentional and will not be changed. [2005-08-06 00:39:22] RVaughn at pheedo dot com As said, these do *not* appear in my php.ini file. You're just making an assumption about that. The paths do *not* appear anywhere in the php.ini (the tests are supposed to ignore the /etc/php.ini file and use the one in the source code anyway, according to README.TESTING) and those weird paths do not appear anywhere on my system nor in the source code. The conclusions you've jumped to are mistaken. Thanks. [2005-08-05 22:39:56] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. [2005-08-05 22:36:53] [EMAIL PROTECTED] It does't look for any libraries (and this is obvius from its source). Fix your system or remove these extensions from your php.ini Not PHP problem. 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/34015 -- Edit this bug report at http://bugs.php.net/?id=34015&edit=1
#34015 [Csd->Opn]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Closed +Status: Open Bug Type: mbstring related Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: Thanks Sniper, for a real answer rather than a rote one. Is there any way to get more info on this bug? Namely, is it a problem with the test script or with PHP or both? I don't want to have to pull a whole new distribution of PHP 4.4 down and build it from scratch; we're trying to run a business. Thanks! Cheers, Rob Previous Comments: [2005-08-06 00:41:59] [EMAIL PROTECTED] Hehe..don't trust everything you read. :) The tests definately use your php.ini. It's intentional and will not be changed. [2005-08-06 00:39:22] RVaughn at pheedo dot com As said, these do *not* appear in my php.ini file. You're just making an assumption about that. The paths do *not* appear anywhere in the php.ini (the tests are supposed to ignore the /etc/php.ini file and use the one in the source code anyway, according to README.TESTING) and those weird paths do not appear anywhere on my system nor in the source code. The conclusions you've jumped to are mistaken. Thanks. [2005-08-05 22:39:56] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. [2005-08-05 22:36:53] [EMAIL PROTECTED] It does't look for any libraries (and this is obvius from its source). Fix your system or remove these extensions from your php.ini Not PHP problem. [2005-08-05 22:23:31] RVaughn at pheedo dot com Description: The 'php_gr_jp_16242.phpt' test script does not look in the proper place for PHP-required libraries, note they look in '/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct spot: '/usr/lib/php4'. Note that this is listed in the '/etc/php.ini' file: ; UNIX: "/path1:/path2" include_path = ".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Errors: PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0 This is on a Red Hat Enterprise 3.0 system with the following configure settings: ./configure 2>configure.err '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-kerberos' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring=/usr/lib/php4/' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' | tee configure.out Repr
#34015 [Opn->Csd]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Closed Bug Type: mbstring related Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: Hehe..don't trust everything you read. :) The tests definately use your php.ini. It's intentional and will not be changed. Previous Comments: [2005-08-06 00:39:22] RVaughn at pheedo dot com As said, these do *not* appear in my php.ini file. You're just making an assumption about that. The paths do *not* appear anywhere in the php.ini (the tests are supposed to ignore the /etc/php.ini file and use the one in the source code anyway, according to README.TESTING) and those weird paths do not appear anywhere on my system nor in the source code. The conclusions you've jumped to are mistaken. Thanks. [2005-08-05 22:39:56] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. [2005-08-05 22:36:53] [EMAIL PROTECTED] It does't look for any libraries (and this is obvius from its source). Fix your system or remove these extensions from your php.ini Not PHP problem. [2005-08-05 22:23:31] RVaughn at pheedo dot com Description: The 'php_gr_jp_16242.phpt' test script does not look in the proper place for PHP-required libraries, note they look in '/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct spot: '/usr/lib/php4'. Note that this is listed in the '/etc/php.ini' file: ; UNIX: "/path1:/path2" include_path = ".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Errors: PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0 This is on a Red Hat Enterprise 3.0 system with the following configure settings: ./configure 2>configure.err '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-kerberos' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring=/usr/lib/php4/' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' | tee configure.out Reproduce code: --- The test script .../ext/mbstring/tests/php_gr_jp_16242.phpt in the PHP 4.4 distro will reproduce this error on this platform. Expected result: The output of the code is correct except for these weird warnings: [...warnings removed...] string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" Actual result: -- EXPECTED OUTPUT string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8"
#34007 [Opn]: cURL compilation fails with GCC 4.x
ID: 34007 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: GNU/Linux PHP Version: 5CVS-2005-08-05 (dev) New Comment: Hint: To not waste our time, always include your configure line in the report. Now I first tried compile, then when it didn't fail or give any warnings even, I checked the sources and noticed that this can only happen when ZTS is enabled.. Previous Comments: [2005-08-05 15:03:10] [EMAIL PROTECTED] Description: Building the latest snapshot of PHP 5.1 with cURL support enabled fails. This seems to be a problem with GCC 4.x only, because it builds fine with GCC 3.3. $ gcc --version gcc (GCC) 4.0.2 20050725 (prerelease) (Debian 4.0.1-3) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Actual result: -- /home/martin/src/php5-200508051030/ext/curl/interface.c: In function 'zif_curl_init': /home/martin/src/php5-200508051030/ext/curl/interface.c:829: error: invalid lvalue in assignment /home/martin/src/php5-200508051030/ext/curl/interface.c: In function 'zif_curl_copy_handle': /home/martin/src/php5-200508051030/ext/curl/interface.c:890: error: invalid lvalue in assignment make: *** [ext/curl/interface.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=34007&edit=1
#34015 [Csd->Opn]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Closed +Status: Open Bug Type: mbstring related Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: As said, these do *not* appear in my php.ini file. You're just making an assumption about that. The paths do *not* appear anywhere in the php.ini (the tests are supposed to ignore the /etc/php.ini file and use the one in the source code anyway, according to README.TESTING) and those weird paths do not appear anywhere on my system nor in the source code. The conclusions you've jumped to are mistaken. Thanks. Previous Comments: [2005-08-05 22:39:56] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. [2005-08-05 22:36:53] [EMAIL PROTECTED] It does't look for any libraries (and this is obvius from its source). Fix your system or remove these extensions from your php.ini Not PHP problem. [2005-08-05 22:23:31] RVaughn at pheedo dot com Description: The 'php_gr_jp_16242.phpt' test script does not look in the proper place for PHP-required libraries, note they look in '/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct spot: '/usr/lib/php4'. Note that this is listed in the '/etc/php.ini' file: ; UNIX: "/path1:/path2" include_path = ".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Errors: PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0 This is on a Red Hat Enterprise 3.0 system with the following configure settings: ./configure 2>configure.err '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-kerberos' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring=/usr/lib/php4/' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' | tee configure.out Reproduce code: --- The test script .../ext/mbstring/tests/php_gr_jp_16242.phpt in the PHP 4.4 distro will reproduce this error on this platform. Expected result: The output of the code is correct except for these weird warnings: [...warnings removed...] string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" Actual result: -- EXPECTED OUTPUT string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" ACTUAL OUTPUT PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object\ file: No such file or directory in Unknown on line 0 PHP
#34006 [Opn->Csd]: CLI phpinfo showing html on odbc.default_pw
ID: 34006
Updated by: [EMAIL PROTECTED]
Reported By: csaba at alum dot mit dot edu
-Status: Open
+Status: Closed
Bug Type:CGI related
PHP Version: 5.1.0b3
New Comment:
This bug has been fixed in CVS.
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.
Problem in summary is fixed. I don't know what you meant with the other
one anyway. Plus we don't like many bugs reported with one report..
Previous Comments:
[2005-08-05 23:57:50] csaba at alum dot mit dot edu
Hi Tony,
I have downloaded from snaps.php.net just now and find that both
issues I reported are still there:
1. the concrete bug report of the () italics are still there when
invoking (CLI) php.exe on the code that I gave (of course, in the code
that I gave you have to search for 'obdc' and then notice that 'no
value' is italicized since the output has gone to the browser). This
is true regardless of whether the ini_set line is invoked or commented
out.
2. The issue that I raised at the end is also not resolved since at
the same time, the output to the browser is otherwise not formatted,
despite having set html_errors to 1
[2005-08-05 11:15:33] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Works just fine here.
[2005-08-05 11:06:51] csaba at alum dot mit dot edu
Description:
If, on my Win XP Pro, I invoke the CLI php.exe or php-win.exe to do:
then I see that only the odbc.default_pw line has html markup:
odbc.default_pw no value no value
That line seems incorrect, being at odds with the rest of the output
generated, which has no html markup.
Expected result:
OK, the reason for this trivial, though real, report is actually to ask
a question, lest I missed something, before filing a suggestion.
A perfectly reasonable thing to do with CLI PHP is to bring up IE and
have it do things, including displaying html formatted phpinfo(), but
the below code will not format it (as is also noted at
http://bugs.php.net/bug.php?id=28405 )
Navigate("about:blank");
$ie->visible = true;
// try to get formatted phpinfo();
ini_set("html_errors", "1");
ob_start();
phpinfo();
$phpinfo = ob_get_contents();
ob_end_clean();
// output it to IE
$ie->Document->Write($phpinfo);
?>
The suggestion that I got at
http://groups-beta.google.com/group/comp.lang.php/browse_frm/thread/8b98f603dcd62123/
was to use the CGI version of PHP. Which works. But that begs the
question of why have the CLI version at all, then.
Thus, my real question is: Wouldn't it make sense to have phpinfo()
respect the html_errors setting, or, have a 2nd, optional argument on
phpinfo() to allow it use the "other" format. Unless it's already
possible or there's a reason not to, I'll presume to file this as a
suggestion.
Thanks,
Csaba Gabor from Vienna
--
Edit this bug report at http://bugs.php.net/?id=34006&edit=1
#34007 [Opn->Csd]: cURL compilation fails with GCC 4.x
ID: 34007 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: GNU/Linux PHP Version: 5CVS-2005-08-05 (dev) New Comment: This bug has been fixed in CVS. 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: [2005-08-06 00:12:17] [EMAIL PROTECTED] Hint: To not waste our time, always include your configure line in the report. Now I first tried compile, then when it didn't fail or give any warnings even, I checked the sources and noticed that this can only happen when ZTS is enabled.. [2005-08-05 15:03:10] [EMAIL PROTECTED] Description: Building the latest snapshot of PHP 5.1 with cURL support enabled fails. This seems to be a problem with GCC 4.x only, because it builds fine with GCC 3.3. $ gcc --version gcc (GCC) 4.0.2 20050725 (prerelease) (Debian 4.0.1-3) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Actual result: -- /home/martin/src/php5-200508051030/ext/curl/interface.c: In function 'zif_curl_init': /home/martin/src/php5-200508051030/ext/curl/interface.c:829: error: invalid lvalue in assignment /home/martin/src/php5-200508051030/ext/curl/interface.c: In function 'zif_curl_copy_handle': /home/martin/src/php5-200508051030/ext/curl/interface.c:890: error: invalid lvalue in assignment make: *** [ext/curl/interface.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=34007&edit=1
#34012 [Opn->Fbk]: PHP segfaults when connecting to MySQL
ID: 34012 Updated by: [EMAIL PROTECTED] Reported By: bjorn dot malmberg at gmail dot com -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Debian Sarge 3.1 PHP Version: 4.4.0 New Comment: 1) What compiler are you using? 2) Where did you get MySQL? Previous Comments: [2005-08-05 19:52:10] bjorn dot malmberg at gmail dot com No I can't... This is the only machine I have with Linux on. I upgraded this machine from Debian 3.0 to 3.1, unfortunately I also upgraded PHP (4.3.11-4.4.0), MySQL (4.0.12?-4.1.13) and Apache (1.3.29-1.3.31) at the same time, so I can't be 100% sure that the cause is the upgrade to Sarge. Both Apache and MySQL by themselves works as expected. For now I could "downgrade" this machine to 3.0 again, but that wouldn't solve the problem for others with 3.1... [2005-08-05 19:36:28] [EMAIL PROTECTED] Could you test it on another machine (that uses something different than Sarge)? That would answer your question, obviuosly. [2005-08-05 19:20:56] bjorn dot malmberg at gmail dot com Description: PHP segfaults on my Debian 3.1 machine when trying to connect to MySQL. MySQL version: 4.1.13-standard Apache version: 1.3.31 PHP version: 4.4.0 PHP configline: ./configure --with-mysql=/usr/local/mysql --enable-track-vars --enable-xslt --with-xslt-sablot --enable-mbstring --with-apxs=/etc/apache/bin/apxs --with-gettext=/usr/bin --enable-sockets --with-gd --with-jpeg-dir=/usr/lib --with-zlib-dir=/usr/include --with-imagick --enable-exif --enable-sockets --enable-posix --with-iconv Backtrace: #0 0x4010139b in mallopt () from /lib/libc.so.6 #1 0x4010015f in free () from /lib/libc.so.6 #2 0x4033179c in _efree (ptr=0x812ec1c) at /usr/src/php/php-4.4.0/Zend/zend_alloc.c:265 #3 0x40290e27 in _close_mysql_link (rsrc=0x812f344) at /usr/src/php/php-4.4.0/ext/mysql/php_mysql.c:297 #4 0x40343434 in list_entry_destructor (ptr=0x812f344) at /usr/src/php/php-4.4.0/Zend/zend_list.c:177 #5 0x403423c9 in zend_hash_apply_deleter (ht=0x40632680, p=0x812a73c) at /usr/src/php/php-4.4.0/Zend/zend_hash.c:611 #6 0x403424ef in zend_hash_graceful_reverse_destroy (ht=0x40632680) at /usr/src/php/php-4.4.0/Zend/zend_hash.c:677 #7 0x40343535 in zend_destroy_rsrc_list (ht=0x40632680) at /usr/src/php/php-4.4.0/Zend/zend_list.c:233 #8 0x40336d93 in shutdown_executor () at /usr/src/php/php-4.4.0/Zend/zend_execute_API.c:211 #9 0x4033e5cd in zend_deactivate () at /usr/src/php/php-4.4.0/Zend/zend.c:693 #10 0x40319085 in php_request_shutdown (dummy=0x0) at /usr/src/php/php-4.4.0/main/main.c:997 #11 0x40356475 in apache_php_module_main (r=0x8125b6c, display_source_mode=0) at /usr/src/php/php-4.4.0/sapi/apache/sapi_apache.c:60 #12 0x40356e02 in send_php (r=0x8125b6c, display_source_mode=0, filename=0x0) at /usr/src/php/php-4.4.0/sapi/apache/mod_php4.c:627 #13 0x40356e51 in send_parsed_php (r=0x8125b6c) at /usr/src/php/php-4.4.0/sapi/apache/mod_php4.c:642 #14 0x0807aad9 in ap_invoke_handler () #15 0x080912bc in process_request_internal () #16 0x08091326 in ap_process_request () #17 0x080879a0 in child_main () #18 0x08087b51 in make_child () #19 0x08087ccc in startup_children () #20 0x080883ed in standalone_main () #21 0x08088c5c in main () I guess this means that PHP doesn't like the version of libc that Sarge is using huh? Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=34012&edit=1
#34006 [Fbk->Opn]: CLI phpinfo showing html on odbc.default_pw
ID: 34006
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type:CGI related
PHP Version: 5.1.0b3
New Comment:
Hi Tony,
I have downloaded from snaps.php.net just now and find that both
issues I reported are still there:
1. the concrete bug report of the () italics are still there when
invoking (CLI) php.exe on the code that I gave (of course, in the code
that I gave you have to search for 'obdc' and then notice that 'no
value' is italicized since the output has gone to the browser). This
is true regardless of whether the ini_set line is invoked or commented
out.
2. The issue that I raised at the end is also not resolved since at
the same time, the output to the browser is otherwise not formatted,
despite having set html_errors to 1
Previous Comments:
[2005-08-05 11:15:33] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Works just fine here.
[2005-08-05 11:06:51] csaba at alum dot mit dot edu
Description:
If, on my Win XP Pro, I invoke the CLI php.exe or php-win.exe to do:
then I see that only the odbc.default_pw line has html markup:
odbc.default_pw no value no value
That line seems incorrect, being at odds with the rest of the output
generated, which has no html markup.
Expected result:
OK, the reason for this trivial, though real, report is actually to ask
a question, lest I missed something, before filing a suggestion.
A perfectly reasonable thing to do with CLI PHP is to bring up IE and
have it do things, including displaying html formatted phpinfo(), but
the below code will not format it (as is also noted at
http://bugs.php.net/bug.php?id=28405 )
Navigate("about:blank");
$ie->visible = true;
// try to get formatted phpinfo();
ini_set("html_errors", "1");
ob_start();
phpinfo();
$phpinfo = ob_get_contents();
ob_end_clean();
// output it to IE
$ie->Document->Write($phpinfo);
?>
The suggestion that I got at
http://groups-beta.google.com/group/comp.lang.php/browse_frm/thread/8b98f603dcd62123/
was to use the CGI version of PHP. Which works. But that begs the
question of why have the CLI version at all, then.
Thus, my real question is: Wouldn't it make sense to have phpinfo()
respect the html_errors setting, or, have a 2nd, optional argument on
phpinfo() to allow it use the "other" format. Unless it's already
possible or there's a reason not to, I'll presume to file this as a
suggestion.
Thanks,
Csaba Gabor from Vienna
--
Edit this bug report at http://bugs.php.net/?id=34006&edit=1
#34011 [Csd]: variables_order not PHP_INI_ALL
ID: 34011 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *Configuration Issues Operating System: all PHP Version: 5CVS-2005-08-05 (dev) New Comment: BTW. It doesn't really make any difference what the level of this option (or any other similar option) has because these options are checked before the script is run. Previous Comments: [2005-08-05 23:44:36] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. [2005-08-05 17:33:49] [EMAIL PROTECTED] Description: I'm not sure if this is a php bug or just a documentation bug. in http://lxr.php.net/source/php-src/main/main.c#305 variables_order is specified as beeing PHP_INI_ALL, so the manual also says that. But I've tested php 5.0.4 in cgi mode and php 5.1 as apache2 module an noone of them respect my ini_set() order, even if I type it in first line of the script (JIT is on). So, should the refering line be changed to INI_SYSTEM & documented the problem properly, or is it a real bug? -- Edit this bug report at http://bugs.php.net/?id=34011&edit=1
#34011 [Opn->Csd]: variables_order not PHP_INI_ALL
ID: 34011 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Configuration Issues Operating System: all PHP Version: 5CVS-2005-08-05 (dev) New Comment: This bug has been fixed in CVS. 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: [2005-08-05 17:33:49] [EMAIL PROTECTED] Description: I'm not sure if this is a php bug or just a documentation bug. in http://lxr.php.net/source/php-src/main/main.c#305 variables_order is specified as beeing PHP_INI_ALL, so the manual also says that. But I've tested php 5.0.4 in cgi mode and php 5.1 as apache2 module an noone of them respect my ini_set() order, even if I type it in first line of the script (JIT is on). So, should the refering line be changed to INI_SYSTEM & documented the problem properly, or is it a real bug? -- Edit this bug report at http://bugs.php.net/?id=34011&edit=1
#34015 [Opn->Csd]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Closed Bug Type: mbstring related Operating System: RHEL 3.0 PHP Version: 4.4.0 Previous Comments: [2005-08-05 22:39:56] [EMAIL PROTECTED] This bug has been fixed in CVS. 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. [2005-08-05 22:36:53] [EMAIL PROTECTED] It does't look for any libraries (and this is obvius from its source). Fix your system or remove these extensions from your php.ini Not PHP problem. [2005-08-05 22:23:31] RVaughn at pheedo dot com Description: The 'php_gr_jp_16242.phpt' test script does not look in the proper place for PHP-required libraries, note they look in '/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct spot: '/usr/lib/php4'. Note that this is listed in the '/etc/php.ini' file: ; UNIX: "/path1:/path2" include_path = ".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Errors: PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0 This is on a Red Hat Enterprise 3.0 system with the following configure settings: ./configure 2>configure.err '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-kerberos' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring=/usr/lib/php4/' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' | tee configure.out Reproduce code: --- The test script .../ext/mbstring/tests/php_gr_jp_16242.phpt in the PHP 4.4 distro will reproduce this error on this platform. Expected result: The output of the code is correct except for these weird warnings: [...warnings removed...] string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" Actual result: -- EXPECTED OUTPUT string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" ACTUAL OUTPUT PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object\ file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object\ file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared obje\ ct file: No such file or directory in Unknown on line 0 PHP Warn
#34015 [Bgs->Opn]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Bogus +Status: Open -Bug Type: Unknown/Other Function +Bug Type: mbstring related Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: This bug has been fixed in CVS. 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: [2005-08-05 22:36:53] [EMAIL PROTECTED] It does't look for any libraries (and this is obvius from its source). Fix your system or remove these extensions from your php.ini Not PHP problem. [2005-08-05 22:23:31] RVaughn at pheedo dot com Description: The 'php_gr_jp_16242.phpt' test script does not look in the proper place for PHP-required libraries, note they look in '/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct spot: '/usr/lib/php4'. Note that this is listed in the '/etc/php.ini' file: ; UNIX: "/path1:/path2" include_path = ".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Errors: PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0 This is on a Red Hat Enterprise 3.0 system with the following configure settings: ./configure 2>configure.err '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-kerberos' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring=/usr/lib/php4/' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' | tee configure.out Reproduce code: --- The test script .../ext/mbstring/tests/php_gr_jp_16242.phpt in the PHP 4.4 distro will reproduce this error on this platform. Expected result: The output of the code is correct except for these weird warnings: [...warnings removed...] string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" Actual result: -- EXPECTED OUTPUT string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" ACTUAL OUTPUT PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object\ file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object\ file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared obje\ ct file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/
#34015 [Opn->Bgs]: Test script php_gr_jp_16242.phpt mislocates libraries
ID: 34015 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: It does't look for any libraries (and this is obvius from its source). Fix your system or remove these extensions from your php.ini Not PHP problem. Previous Comments: [2005-08-05 22:23:31] RVaughn at pheedo dot com Description: The 'php_gr_jp_16242.phpt' test script does not look in the proper place for PHP-required libraries, note they look in '/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct spot: '/usr/lib/php4'. Note that this is listed in the '/etc/php.ini' file: ; UNIX: "/path1:/path2" include_path = ".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Errors: PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0 This is on a Red Hat Enterprise 3.0 system with the following configure settings: ./configure 2>configure.err '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-kerberos' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring=/usr/lib/php4/' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' | tee configure.out Reproduce code: --- The test script .../ext/mbstring/tests/php_gr_jp_16242.phpt in the PHP 4.4 distro will reproduce this error on this platform. Expected result: The output of the code is correct except for these weird warnings: [...warnings removed...] string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" Actual result: -- EXPECTED OUTPUT string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" ACTUAL OUTPUT PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object\ file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object\ file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared obje\ ct file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared obje\ ct file: No such file or directory in Unknown on line 0 string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" -- Edit this bug report at http://bugs.php.net/?id=34015&edit=1
#34008 [Opn->Csd]: Make file error
ID: 34008 Updated by: [EMAIL PROTECTED] Reported By: ljanda at checkstop dot com -Status: Open +Status: Closed Bug Type: *Compile Issues Operating System: SCO 5.05 PHP Version: 4.4.0 New Comment: This bug has been fixed in CVS. 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. Sometimes simple things cause big problems. It was actually just one missing empty line in the beginning of ext/informix/Makefile.frag Previous Comments: [2005-08-05 20:48:46] ljanda at checkstop dot com OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c Also the above is supposed to be a directory?? failing in make install [2005-08-05 20:47:13] ljanda at checkstop dot com Have no access to other servers [2005-08-05 19:51:22] [EMAIL PROTECTED] Are you able to reproduce on non-SCO server? [2005-08-05 15:37:14] ljanda at checkstop dot com Description: Simple problem in configure: ./configure --without-mysql --with-informix --with-apache=../apache_1.3.19 --ena ble-shared --enable-track-vars Adding the Informix puts a line into make file without tab (\t) and therefore the make fails. Looked and makefile and sure enough, the line was left justified, put the tab in and got it to work. Reproduce code: --- install-cli: $(SAPI_CLI_PATH) @echo "Installing PHP CLI binary:$(INSTALL_ROOT)$(bindir)/" @$(INSTALL_CLI) @echo "Installing PHP CLI man page: $(INSTALL_ROOT)$(mandir)/man1/" @$(mkinstalldirs) $(INSTALL_ROOT)$(mandir)/man1 @$(INSTALL_DATA) sapi/cli/php.1 $(INSTALL_ROOT)$(mandir)/man1/php.1 /*** this line needs a tab OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c /u/leroy/php- Expected result: make error -- Edit this bug report at http://bugs.php.net/?id=34008&edit=1
#34015 [NEW]: Test script php_gr_jp_16242.phpt mislocates libraries
From: RVaughn at pheedo dot com Operating system: RHEL 3.0 PHP version: 4.4.0 PHP Bug Type: Unknown/Other Function Bug description: Test script php_gr_jp_16242.phpt mislocates libraries Description: The 'php_gr_jp_16242.phpt' test script does not look in the proper place for PHP-required libraries, note they look in '/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct spot: '/usr/lib/php4'. Note that this is listed in the '/etc/php.ini' file: ; UNIX: "/path1:/path2" include_path = ".:/php/includes:/usr/lib/php4:/usr/local/lib/php" Errors: PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/20020429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0 This is on a Red Hat Enterprise 3.0 system with the following configure settings: ./configure 2>configure.err '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-kerberos' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring=/usr/lib/php4/' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' | tee configure.out Reproduce code: --- The test script .../ext/mbstring/tests/php_gr_jp_16242.phpt in the PHP 4.4 distro will reproduce this error on this platform. Expected result: The output of the code is correct except for these weird warnings: [...warnings removed...] string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" Actual result: -- EXPECTED OUTPUT string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" ACTUAL OUTPUT PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared object\ file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared object\ file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared obje\ ct file: No such file or directory in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/local/lib/php/200\ 20429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared obje\ ct file: No such file or directory in Unknown on line 0 string(8) "Japanese" string(5) "UTF-8" string(5) "UTF-8" -- Edit bug report at http://bugs.php.net/?id=34015&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34015&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34015&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34015&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34015&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34015&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34015&r=needtr
#33997 [Csd->Asn]: Returned: Bug #16069 - ICONV transliteration failure
ID: 33997 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Closed +Status: Assigned Bug Type: ICONV related Operating System: Red Hat Ent. 3.0 PHP Version: 5CVS, 4CVS (2005-08-04) Assigned To: yohgaki New Comment: Well, the patch is not approved/applied to CVS yet so keep this report open. We'll close this once the bug is really fixed. Previous Comments: [2005-08-05 01:18:33] RVaughn at pheedo dot com Works perfectly! Hopefully this patch can be rolled into PHP 4.4.1? This one can be closed, that was the fix. Thanks much! Cheers! [2005-08-05 00:39:44] [EMAIL PROTECTED] This seems to fix the problem: http://www.php.net/~jani/patches/bug33997.patch I now get the correct result which I also got with the command line iconv tool. [2005-08-04 23:34:18] RVaughn at pheedo dot com Do let me know if you want me to put the output somewhere on our site where it can be downloaded, the code itself is just the PHP-provided test: bug16069.phpt. Thanks! Cheers! [2005-08-04 23:32:57] RVaughn at pheedo dot com OK, here's the diff output from the test results, please note that the output is the same until part way through, and the ultimate length is different: === /usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt === EXPECTED OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) ACTUAL OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) FAILED [2005-08-04 22:42:12] [EMAIL PROTECTED] If it fails, you should get *.diff file which clearly shows what did you get instead of the result expected. And you don't have to post something, you can just put the code and it's output somewhere in the Net and post a link here. 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/33997 -- Edit this bug report at http://bugs.php.net/?id=33997&edit=1
#34014 [Opn->Bgs]: make install fails
ID: 34014 Updated by: [EMAIL PROTECTED] Reported By: ljanda at checkstop dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: SCO 5.05 PHP Version: 4.4.0 New Comment: No need to post reports twice. Previous Comments: [2005-08-05 21:06:10] ljanda at checkstop dot com Description: make install fails in informix part. Looks as though the compile went ok as libs are there. cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la libtool: install: warning: remember to run `libtool --finish /u/leroy/php-4.4.0/libs' chmod 755 /usr/local/apache2/modules/libphp4.so [activating module `php4' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/php/bin/ Installing PHP CLI man page: /usr/local/php/man/man1/ OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c sh: OVERALL_TARGET: not found *** Error code 1 (bu21) ** above ls on directory drwxr-xr-x 2 leroyinform 512 Aug 5 14:00 .libs -rw-r--r-- 1 leroyinform57 Feb 25 2003 CREDITS -rw-r--r-- 1 leroyinform 454 May 30 2004 Makefile.frag -rw-r--r-- 1 leroyinform 3039 Feb 25 2003 config.m4 -rw-r--r-- 1 leroyinform185957 Aug 5 13:58 ifx.c -rw-r--r-- 1 leroyinform 5326 Sep 8 2003 ifx.dsp -rw-r--r-- 1 leroyinform137069 Dec 16 2004 ifx.ec -rw-r--r-- 1 root sys 224092 Aug 5 14:00 ifx.lo -rw-r--r-- 1 root sys 224092 Aug 5 14:00 ifx.o@ -rw-r--r-- 1 leroyinform 1060 Aug 5 13:53 libphpifx.a -rw-r--r-- 1 leroyinform 4225 Feb 25 2003 php_informix.h -rw-r--r-- 1 leroyinform 2633 Feb 25 2003 php_informix_includes.h # -- Edit this bug report at http://bugs.php.net/?id=34014&edit=1
#34014 [NEW]: make install fails
From: ljanda at checkstop dot com Operating system: SCO 5.05 PHP version: 4.4.0 PHP Bug Type: *Configuration Issues Bug description: make install fails Description: make install fails in informix part. Looks as though the compile went ok as libs are there. cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la libtool: install: warning: remember to run `libtool --finish /u/leroy/php-4.4.0/libs' chmod 755 /usr/local/apache2/modules/libphp4.so [activating module `php4' in /usr/local/apache2/conf/httpd.conf] Installing PHP CLI binary:/usr/local/php/bin/ Installing PHP CLI man page: /usr/local/php/man/man1/ OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c sh: OVERALL_TARGET: not found *** Error code 1 (bu21) ** above ls on directory drwxr-xr-x 2 leroyinform 512 Aug 5 14:00 .libs -rw-r--r-- 1 leroyinform57 Feb 25 2003 CREDITS -rw-r--r-- 1 leroyinform 454 May 30 2004 Makefile.frag -rw-r--r-- 1 leroyinform 3039 Feb 25 2003 config.m4 -rw-r--r-- 1 leroyinform185957 Aug 5 13:58 ifx.c -rw-r--r-- 1 leroyinform 5326 Sep 8 2003 ifx.dsp -rw-r--r-- 1 leroyinform137069 Dec 16 2004 ifx.ec -rw-r--r-- 1 root sys 224092 Aug 5 14:00 ifx.lo -rw-r--r-- 1 root sys 224092 Aug 5 14:00 ifx.o@ -rw-r--r-- 1 leroyinform 1060 Aug 5 13:53 libphpifx.a -rw-r--r-- 1 leroyinform 4225 Feb 25 2003 php_informix.h -rw-r--r-- 1 leroyinform 2633 Feb 25 2003 php_informix_includes.h # -- Edit bug report at http://bugs.php.net/?id=34014&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34014&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34014&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34014&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34014&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34014&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34014&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34014&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34014&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34014&r=support Expected behavior: http://bugs.php.net/fix.php?id=34014&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34014&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34014&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34014&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34014&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34014&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34014&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34014&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34014&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34014&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34014&r=mysqlcfg
#34013 [Opn->Fbk]: setlocale used from php-cli does not set locale
ID: 34013 Updated by: [EMAIL PROTECTED] Reported By: wim dot delvaux at adaptiveplanet dot com -Status: Open +Status: Feedback Bug Type: CGI related Operating System: debian sed PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip And check that you have this locale first with: locale -a | grep nl Previous Comments: [2005-08-05 20:56:52] wim dot delvaux at adaptiveplanet dot com Description: setlocale used from apache module seems to work however using the same setlocale setlocale( LC_TIME, 'nl_NL' ); in a php script started from the command line does not work (i.e. month names are not NL but remain EN Reproduce code: --- produces August and not Augustus Expected result: Should output Augustus -- Edit this bug report at http://bugs.php.net/?id=34013&edit=1
#34013 [NEW]: setlocale used from php-cli does not set locale
From: wim dot delvaux at adaptiveplanet dot com Operating system: debian sed PHP version: 5.0.4 PHP Bug Type: CGI related Bug description: setlocale used from php-cli does not set locale Description: setlocale used from apache module seems to work however using the same setlocale setlocale( LC_TIME, 'nl_NL' ); in a php script started from the command line does not work (i.e. month names are not NL but remain EN Reproduce code: --- produces August and not Augustus Expected result: Should output Augustus -- Edit bug report at http://bugs.php.net/?id=34013&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34013&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34013&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34013&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34013&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34013&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34013&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34013&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34013&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34013&r=support Expected behavior: http://bugs.php.net/fix.php?id=34013&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34013&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34013&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34013&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34013&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34013&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34013&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34013&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34013&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34013&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34013&r=mysqlcfg
#34008 [Opn]: Make file error
ID: 34008 User updated by: ljanda at checkstop dot com Reported By: ljanda at checkstop dot com Status: Open Bug Type: *Compile Issues Operating System: SCO 5.05 PHP Version: 4.4.0 New Comment: OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c Also the above is supposed to be a directory?? failing in make install Previous Comments: [2005-08-05 20:47:13] ljanda at checkstop dot com Have no access to other servers [2005-08-05 19:51:22] [EMAIL PROTECTED] Are you able to reproduce on non-SCO server? [2005-08-05 15:37:14] ljanda at checkstop dot com Description: Simple problem in configure: ./configure --without-mysql --with-informix --with-apache=../apache_1.3.19 --ena ble-shared --enable-track-vars Adding the Informix puts a line into make file without tab (\t) and therefore the make fails. Looked and makefile and sure enough, the line was left justified, put the tab in and got it to work. Reproduce code: --- install-cli: $(SAPI_CLI_PATH) @echo "Installing PHP CLI binary:$(INSTALL_ROOT)$(bindir)/" @$(INSTALL_CLI) @echo "Installing PHP CLI man page: $(INSTALL_ROOT)$(mandir)/man1/" @$(mkinstalldirs) $(INSTALL_ROOT)$(mandir)/man1 @$(INSTALL_DATA) sapi/cli/php.1 $(INSTALL_ROOT)$(mandir)/man1/php.1 /*** this line needs a tab OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c /u/leroy/php- Expected result: make error -- Edit this bug report at http://bugs.php.net/?id=34008&edit=1
#34008 [Fbk->Opn]: Make file error
ID: 34008 User updated by: ljanda at checkstop dot com Reported By: ljanda at checkstop dot com -Status: Feedback +Status: Open Bug Type: *Compile Issues Operating System: SCO 5.05 PHP Version: 4.4.0 New Comment: Have no access to other servers Previous Comments: [2005-08-05 19:51:22] [EMAIL PROTECTED] Are you able to reproduce on non-SCO server? [2005-08-05 15:37:14] ljanda at checkstop dot com Description: Simple problem in configure: ./configure --without-mysql --with-informix --with-apache=../apache_1.3.19 --ena ble-shared --enable-track-vars Adding the Informix puts a line into make file without tab (\t) and therefore the make fails. Looked and makefile and sure enough, the line was left justified, put the tab in and got it to work. Reproduce code: --- install-cli: $(SAPI_CLI_PATH) @echo "Installing PHP CLI binary:$(INSTALL_ROOT)$(bindir)/" @$(INSTALL_CLI) @echo "Installing PHP CLI man page: $(INSTALL_ROOT)$(mandir)/man1/" @$(mkinstalldirs) $(INSTALL_ROOT)$(mandir)/man1 @$(INSTALL_DATA) sapi/cli/php.1 $(INSTALL_ROOT)$(mandir)/man1/php.1 /*** this line needs a tab OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c /u/leroy/php- Expected result: make error -- Edit this bug report at http://bugs.php.net/?id=34008&edit=1
#34009 [Opn->Fbk]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009
Updated by: [EMAIL PROTECTED]
Reported By: ast at gmx dot ch
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 4.4.0
New Comment:
Please try CVS snapshot first (I've given the link to it).
I have no idea how to look into something that is not reproducible, so
I'd appreciate if you give some guidelines (an account on a machine
would be fine).
Previous Comments:
[2005-08-05 20:02:42] ast at gmx dot ch
That's my point. It doesn't work on all systems.
It works on two of my systems, both running PHP 4.4.0.
It doesn't work on 3 other systems I have access to test the reproduce
code.
I've listed the PHPinfo links and some systems specs of systems that
pass the test and systems that don't pass the test. All of them are
running PHP 4.4.0.
I'd really appreciate if you could look into the issue with your
indepth knowledge of PHP.
[2005-08-05 19:56:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Works fine here.
[2005-08-05 19:50:05] ast at gmx dot ch
Here's the reproduce code:
foo();
class Bug {
var $_flag;
function Bug() {
$this->_flag = 0;
}
function &foo() {
if (!$this->_flag) {
$false = false;
return $false; /* this is line 18 */
}
$false = false;
return $false;
}
}
?>
Expected result:
no NOTICEs
Actual result:
--
Notice: Only variable references should be returned by reference in
reproduce.php on line 18
I've added the two other methods in the original reproduce code just to
show that very slight modifications of the code do not give a PHP
Notice.
And please remember that I can't reproduce it on all systems.
[2005-08-05 19:39:34] [EMAIL PROTECTED]
Please provide an exact reproduce code (the URL you've given contains a
lot of code snippets and I can't understand which one of them is the
reproduce case).
[2005-08-05 18:01:08] ast at gmx dot ch
>From the reproduce script:
Unexpected result oberserved on
- http://nl01.pcextreme.nl/phpinfo.php (PHP 4.4.0, Linux Linux i686)
- PHP 4.4.0 cgi hosted by Powweb.com, Apache/1.3.33 (Unix)
FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7d PowWeb/1.1, FreeBSD
clust05-www01.powweb.com 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Thu Ma
i386
- Gentoo linux, PHP 4.4.0, apache 2, x86:
http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_with_bug.html
Correct behavior observed on
- dozens / hundreds other servers, e.g.
- Windows XP SP 2, PHP 4.4.0 cgi, apache 2, x86
- Gentoo linux, PHP 4.4.0, apache 2, x86:
http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_without_bug.html
(this is another gentoo box, completely unrelated to the other)
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/34009
--
Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34009 [Fbk->Opn]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 4.4.0
New Comment:
That's my point. It doesn't work on all systems.
It works on two of my systems, both running PHP 4.4.0.
It doesn't work on 3 other systems I have access to test the reproduce
code.
I've listed the PHPinfo links and some systems specs of systems that
pass the test and systems that don't pass the test. All of them are
running PHP 4.4.0.
I'd really appreciate if you could look into the issue with your
indepth knowledge of PHP.
Previous Comments:
[2005-08-05 19:56:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Works fine here.
[2005-08-05 19:50:05] ast at gmx dot ch
Here's the reproduce code:
foo();
class Bug {
var $_flag;
function Bug() {
$this->_flag = 0;
}
function &foo() {
if (!$this->_flag) {
$false = false;
return $false; /* this is line 18 */
}
$false = false;
return $false;
}
}
?>
Expected result:
no NOTICEs
Actual result:
--
Notice: Only variable references should be returned by reference in
reproduce.php on line 18
I've added the two other methods in the original reproduce code just to
show that very slight modifications of the code do not give a PHP
Notice.
And please remember that I can't reproduce it on all systems.
[2005-08-05 19:39:34] [EMAIL PROTECTED]
Please provide an exact reproduce code (the URL you've given contains a
lot of code snippets and I can't understand which one of them is the
reproduce case).
[2005-08-05 18:01:08] ast at gmx dot ch
>From the reproduce script:
Unexpected result oberserved on
- http://nl01.pcextreme.nl/phpinfo.php (PHP 4.4.0, Linux Linux i686)
- PHP 4.4.0 cgi hosted by Powweb.com, Apache/1.3.33 (Unix)
FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7d PowWeb/1.1, FreeBSD
clust05-www01.powweb.com 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Thu Ma
i386
- Gentoo linux, PHP 4.4.0, apache 2, x86:
http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_with_bug.html
Correct behavior observed on
- dozens / hundreds other servers, e.g.
- Windows XP SP 2, PHP 4.4.0 cgi, apache 2, x86
- Gentoo linux, PHP 4.4.0, apache 2, x86:
http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_without_bug.html
(this is another gentoo box, completely unrelated to the other)
[2005-08-05 16:41:18] ast at gmx dot ch
Sorry, the first link was incorrect :/
(Coding recommendations)
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=153254#153254
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/34009
--
Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34009 [Opn->Fbk]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009
Updated by: [EMAIL PROTECTED]
Reported By: ast at gmx dot ch
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 4.4.0
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Works fine here.
Previous Comments:
[2005-08-05 19:50:05] ast at gmx dot ch
Here's the reproduce code:
foo();
class Bug {
var $_flag;
function Bug() {
$this->_flag = 0;
}
function &foo() {
if (!$this->_flag) {
$false = false;
return $false; /* this is line 18 */
}
$false = false;
return $false;
}
}
?>
Expected result:
no NOTICEs
Actual result:
--
Notice: Only variable references should be returned by reference in
reproduce.php on line 18
I've added the two other methods in the original reproduce code just to
show that very slight modifications of the code do not give a PHP
Notice.
And please remember that I can't reproduce it on all systems.
[2005-08-05 19:39:34] [EMAIL PROTECTED]
Please provide an exact reproduce code (the URL you've given contains a
lot of code snippets and I can't understand which one of them is the
reproduce case).
[2005-08-05 18:01:08] ast at gmx dot ch
>From the reproduce script:
Unexpected result oberserved on
- http://nl01.pcextreme.nl/phpinfo.php (PHP 4.4.0, Linux Linux i686)
- PHP 4.4.0 cgi hosted by Powweb.com, Apache/1.3.33 (Unix)
FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7d PowWeb/1.1, FreeBSD
clust05-www01.powweb.com 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Thu Ma
i386
- Gentoo linux, PHP 4.4.0, apache 2, x86:
http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_with_bug.html
Correct behavior observed on
- dozens / hundreds other servers, e.g.
- Windows XP SP 2, PHP 4.4.0 cgi, apache 2, x86
- Gentoo linux, PHP 4.4.0, apache 2, x86:
http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_without_bug.html
(this is another gentoo box, completely unrelated to the other)
[2005-08-05 16:41:18] ast at gmx dot ch
Sorry, the first link was incorrect :/
(Coding recommendations)
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=153254#153254
[2005-08-05 16:27:54] ast at gmx dot ch
Description:
Abstract:
---
PHP 4.4.0 shows a "Notice: Only variable references should be returned
by reference in ..." Notice when it shouldn't.
The bug can only be reproduced with PHP 4.4.0. And it can only be
reproduced on a few systems, on most it returns the expected result
(all test platforms had error_reporting(E_ALL);).
Furthermore, code that seems to be equivalent doesn't result in a
Notice. And two different systems with almost the same setup don't show
the same results.
I couldn't isolate the bug further than this. Maybe it's a compile
options issue, maybe it has to do with the scope of variables, I don't
know.
Disclaimer:
---
You may think this is another bogus bug report for the
return-by-reference / assign-by-reference / pass-by-reference Notices
in PHP 4.4.0.
But I'm quite sure it isn't. I've patched our framework and wrote some
recommendations on how to code the right way:
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=32907
. But you don't need to follow this link. I just want to point out that
this is a real issue.
Details:
---
Please take a look at the reproduce script.
Reproduce code:
---
http://dev.nei.ch/bugs/php440_notice_bug/php440_notice_bug_on_certain_platforms.phps
Expected result:
Expected result:
PHP Version is: 4.4.0
no NOTICEs
Actual result:
--
Actual result:
--
php version is: 4.4.0
Notice: Only variable references should be returned by reference in
php440_notice_bug_on_certain_platforms.php on line 23
--
Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34012 [Fbk->Opn]: PHP segfaults when connecting to MySQL
ID: 34012 User updated by: bjorn dot malmberg at gmail dot com Reported By: bjorn dot malmberg at gmail dot com -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Debian Sarge 3.1 PHP Version: 4.4.0 New Comment: No I can't... This is the only machine I have with Linux on. I upgraded this machine from Debian 3.0 to 3.1, unfortunately I also upgraded PHP (4.3.11-4.4.0), MySQL (4.0.12?-4.1.13) and Apache (1.3.29-1.3.31) at the same time, so I can't be 100% sure that the cause is the upgrade to Sarge. Both Apache and MySQL by themselves works as expected. For now I could "downgrade" this machine to 3.0 again, but that wouldn't solve the problem for others with 3.1... Previous Comments: [2005-08-05 19:36:28] [EMAIL PROTECTED] Could you test it on another machine (that uses something different than Sarge)? That would answer your question, obviuosly. [2005-08-05 19:20:56] bjorn dot malmberg at gmail dot com Description: PHP segfaults on my Debian 3.1 machine when trying to connect to MySQL. MySQL version: 4.1.13-standard Apache version: 1.3.31 PHP version: 4.4.0 PHP configline: ./configure --with-mysql=/usr/local/mysql --enable-track-vars --enable-xslt --with-xslt-sablot --enable-mbstring --with-apxs=/etc/apache/bin/apxs --with-gettext=/usr/bin --enable-sockets --with-gd --with-jpeg-dir=/usr/lib --with-zlib-dir=/usr/include --with-imagick --enable-exif --enable-sockets --enable-posix --with-iconv Backtrace: #0 0x4010139b in mallopt () from /lib/libc.so.6 #1 0x4010015f in free () from /lib/libc.so.6 #2 0x4033179c in _efree (ptr=0x812ec1c) at /usr/src/php/php-4.4.0/Zend/zend_alloc.c:265 #3 0x40290e27 in _close_mysql_link (rsrc=0x812f344) at /usr/src/php/php-4.4.0/ext/mysql/php_mysql.c:297 #4 0x40343434 in list_entry_destructor (ptr=0x812f344) at /usr/src/php/php-4.4.0/Zend/zend_list.c:177 #5 0x403423c9 in zend_hash_apply_deleter (ht=0x40632680, p=0x812a73c) at /usr/src/php/php-4.4.0/Zend/zend_hash.c:611 #6 0x403424ef in zend_hash_graceful_reverse_destroy (ht=0x40632680) at /usr/src/php/php-4.4.0/Zend/zend_hash.c:677 #7 0x40343535 in zend_destroy_rsrc_list (ht=0x40632680) at /usr/src/php/php-4.4.0/Zend/zend_list.c:233 #8 0x40336d93 in shutdown_executor () at /usr/src/php/php-4.4.0/Zend/zend_execute_API.c:211 #9 0x4033e5cd in zend_deactivate () at /usr/src/php/php-4.4.0/Zend/zend.c:693 #10 0x40319085 in php_request_shutdown (dummy=0x0) at /usr/src/php/php-4.4.0/main/main.c:997 #11 0x40356475 in apache_php_module_main (r=0x8125b6c, display_source_mode=0) at /usr/src/php/php-4.4.0/sapi/apache/sapi_apache.c:60 #12 0x40356e02 in send_php (r=0x8125b6c, display_source_mode=0, filename=0x0) at /usr/src/php/php-4.4.0/sapi/apache/mod_php4.c:627 #13 0x40356e51 in send_parsed_php (r=0x8125b6c) at /usr/src/php/php-4.4.0/sapi/apache/mod_php4.c:642 #14 0x0807aad9 in ap_invoke_handler () #15 0x080912bc in process_request_internal () #16 0x08091326 in ap_process_request () #17 0x080879a0 in child_main () #18 0x08087b51 in make_child () #19 0x08087ccc in startup_children () #20 0x080883ed in standalone_main () #21 0x08088c5c in main () I guess this means that PHP doesn't like the version of libc that Sarge is using huh? Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=34012&edit=1
#34008 [Opn->Fbk]: Make file error
ID: 34008 Updated by: [EMAIL PROTECTED] Reported By: ljanda at checkstop dot com -Status: Open +Status: Feedback -Bug Type: *Configuration Issues +Bug Type: *Compile Issues Operating System: SCO 5.05 PHP Version: 4.4.0 New Comment: Are you able to reproduce on non-SCO server? Previous Comments: [2005-08-05 15:37:14] ljanda at checkstop dot com Description: Simple problem in configure: ./configure --without-mysql --with-informix --with-apache=../apache_1.3.19 --ena ble-shared --enable-track-vars Adding the Informix puts a line into make file without tab (\t) and therefore the make fails. Looked and makefile and sure enough, the line was left justified, put the tab in and got it to work. Reproduce code: --- install-cli: $(SAPI_CLI_PATH) @echo "Installing PHP CLI binary:$(INSTALL_ROOT)$(bindir)/" @$(INSTALL_CLI) @echo "Installing PHP CLI man page: $(INSTALL_ROOT)$(mandir)/man1/" @$(mkinstalldirs) $(INSTALL_ROOT)$(mandir)/man1 @$(INSTALL_DATA) sapi/cli/php.1 $(INSTALL_ROOT)$(mandir)/man1/php.1 /*** this line needs a tab OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c /u/leroy/php- Expected result: make error -- Edit this bug report at http://bugs.php.net/?id=34008&edit=1
#34009 [Fbk->Opn]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 4.4.0
New Comment:
Here's the reproduce code:
foo();
class Bug {
var $_flag;
function Bug() {
$this->_flag = 0;
}
function &foo() {
if (!$this->_flag) {
$false = false;
return $false; /* this is line 18 */
}
$false = false;
return $false;
}
}
?>
Expected result:
no NOTICEs
Actual result:
--
Notice: Only variable references should be returned by reference in
reproduce.php on line 18
I've added the two other methods in the original reproduce code just to
show that very slight modifications of the code do not give a PHP
Notice.
And please remember that I can't reproduce it on all systems.
Previous Comments:
[2005-08-05 19:39:34] [EMAIL PROTECTED]
Please provide an exact reproduce code (the URL you've given contains a
lot of code snippets and I can't understand which one of them is the
reproduce case).
[2005-08-05 18:01:08] ast at gmx dot ch
>From the reproduce script:
Unexpected result oberserved on
- http://nl01.pcextreme.nl/phpinfo.php (PHP 4.4.0, Linux Linux i686)
- PHP 4.4.0 cgi hosted by Powweb.com, Apache/1.3.33 (Unix)
FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7d PowWeb/1.1, FreeBSD
clust05-www01.powweb.com 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Thu Ma
i386
- Gentoo linux, PHP 4.4.0, apache 2, x86:
http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_with_bug.html
Correct behavior observed on
- dozens / hundreds other servers, e.g.
- Windows XP SP 2, PHP 4.4.0 cgi, apache 2, x86
- Gentoo linux, PHP 4.4.0, apache 2, x86:
http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_without_bug.html
(this is another gentoo box, completely unrelated to the other)
[2005-08-05 16:41:18] ast at gmx dot ch
Sorry, the first link was incorrect :/
(Coding recommendations)
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=153254#153254
[2005-08-05 16:27:54] ast at gmx dot ch
Description:
Abstract:
---
PHP 4.4.0 shows a "Notice: Only variable references should be returned
by reference in ..." Notice when it shouldn't.
The bug can only be reproduced with PHP 4.4.0. And it can only be
reproduced on a few systems, on most it returns the expected result
(all test platforms had error_reporting(E_ALL);).
Furthermore, code that seems to be equivalent doesn't result in a
Notice. And two different systems with almost the same setup don't show
the same results.
I couldn't isolate the bug further than this. Maybe it's a compile
options issue, maybe it has to do with the scope of variables, I don't
know.
Disclaimer:
---
You may think this is another bogus bug report for the
return-by-reference / assign-by-reference / pass-by-reference Notices
in PHP 4.4.0.
But I'm quite sure it isn't. I've patched our framework and wrote some
recommendations on how to code the right way:
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=32907
. But you don't need to follow this link. I just want to point out that
this is a real issue.
Details:
---
Please take a look at the reproduce script.
Reproduce code:
---
http://dev.nei.ch/bugs/php440_notice_bug/php440_notice_bug_on_certain_platforms.phps
Expected result:
Expected result:
PHP Version is: 4.4.0
no NOTICEs
Actual result:
--
Actual result:
--
php version is: 4.4.0
Notice: Only variable references should be returned by reference in
php440_notice_bug_on_certain_platforms.php on line 23
--
Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34004 [Opn->Bgs]: an fatal error on php5ts.dll
ID: 34004
Updated by: [EMAIL PROTECTED]
Reported By: kenji at neojin dot com
-Status: Open
+Status: Bogus
-Bug Type: *Web Server problem
+Bug Type: Unknown/Other Function
Operating System: windows xp
PHP Version: 5.0.4
New Comment:
The code you've provided does nothing, it doesn't contain even a
function call. And it works perfectly with any data I pass to the
function.
Please reopen the report when you have a *short* but *complete*
reproduce script that clearly shows your problem.
Until then -> bogus.
Previous Comments:
[2005-08-05 15:38:27] kenji at neojin dot com
i find the bug
this fonction create the fatal error with apache and php5ts.dll on my
computer
i delete her and all it's ok
when i replace this fonction => fatal error
i hope that you help
[2005-08-05 13:47:48] [EMAIL PROTECTED]
Please provide a short but *COMPLETE* reproduce script, so we can
copy/paste it and reproduce your problem.
Thank you.
[2005-08-05 13:42:23] kenji at neojin dot com
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is
alaways the same
Reproduce code:
---
Send_Query("SELECT * FROM file_xml");
if($objet = $Bdd -> get_object($result)){
$id_file = $objet -> id_file_xml;
}
if($id_file<>''){
if(file_exists('../../cache/liste'.$id_file.'.xml')){
@unlink('../../cache/liste'.$id_file.'.xml');
}
$Bdd -> Send_Query("DELETE FROM file_xml");
}
$Bdd -> Send_Query("INSERT INTO file_xml (date,heure)
VALUES
(now(),now())");
$id_xml = $Bdd -> insert_id();
/*$xml = '';*/
$xml .= '';
$i = 1;
$result = $Bdd -> Send_Query("SELECT * FROM maisons");
while($objet = $Bdd -> get_object($result)){
$nom = stripslashes($objet -> m_nom);
$xml .= '
';
}
$xml .= '';
$handle = fopen('../../cache/liste'.$id_xml.'.xml',
'w+');
fwrite($handle, $xml);
fclose($handle);
?>
hello
the problem is the script is in my own develeppement server offline
i have uninstall and reinstall windows and just install apache / php
for test but the result is same witdh the script
if i comment this script all it s ok
i don't understand why this bug
i tried this script under another server width apache 1.3.23 and php
5.0.4 and it s ok
my computer :
p4 3.0
2 go ram
ati x700 pro
win xp sp2
the problem can be width ram ?
sorry another script are ok
just this not works and several error width windows appear
ps : sorry for my english
[2005-08-05 10:45:49] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-08-05 10:44:35] kenji at neojin dot com
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is
alaways the same
Reproduce code:
---
function sansac
#33995 [Opn->Fbk]: wrong WARNING message
ID: 33995 Updated by: [EMAIL PROTECTED] Reported By: zxc at zmail dot ru -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: What FTP server do you use? (software name, version etc.) Is it a public server? Can you give us it's IP/hostname? And probably we'll need an account there too, if it rejects anonymous logins. Previous Comments: [2005-08-05 19:34:59] zxc at zmail dot ru sniper, I use 3 parameters: I have WARNING message (from "ftp_login()" function) if remote FTP server is FULL (many users etc.) But I must have boolean FALSE only from ftp_login() function in this case (without WARNING message), because I use prefix "@" before "ftp_login()". [2005-08-04 22:12:22] [EMAIL PROTECTED] You have to provide a working script. The one here can not work: ftp_login() expects 3 parameters, not 2.. (and I can't reproduce this with a proper script, even if the server shows errors) [2005-08-04 19:59:47] zxc at zmail dot ru Tony, I has tried change a FTP server to something, but I show WARNING still. [2005-08-04 19:56:42] zxc at zmail dot ru Example of WARNING: -- Warning: ftp_login(): Too many users - please try again later. in /pub/home/hissite/ftpconnect.php on line 73 -- Why shows a WARNING message? I use a "@" prefix before "ftp_login()" function. >>> I must have boolean FALSE only, without this WARNING. [2005-08-04 15:18:54] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. What warning? Which FTP server do you use? How to reproduce it? Are you able to reproduce it if you change your FTP server to something else? 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/33995 -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#34009 [Opn->Fbk]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009 Updated by: [EMAIL PROTECTED] Reported By: ast at gmx dot ch -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 4.4.0 New Comment: Please provide an exact reproduce code (the URL you've given contains a lot of code snippets and I can't understand which one of them is the reproduce case). Previous Comments: [2005-08-05 18:01:08] ast at gmx dot ch >From the reproduce script: Unexpected result oberserved on - http://nl01.pcextreme.nl/phpinfo.php (PHP 4.4.0, Linux Linux i686) - PHP 4.4.0 cgi hosted by Powweb.com, Apache/1.3.33 (Unix) FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7d PowWeb/1.1, FreeBSD clust05-www01.powweb.com 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Thu Ma i386 - Gentoo linux, PHP 4.4.0, apache 2, x86: http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_with_bug.html Correct behavior observed on - dozens / hundreds other servers, e.g. - Windows XP SP 2, PHP 4.4.0 cgi, apache 2, x86 - Gentoo linux, PHP 4.4.0, apache 2, x86: http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_without_bug.html (this is another gentoo box, completely unrelated to the other) [2005-08-05 16:41:18] ast at gmx dot ch Sorry, the first link was incorrect :/ (Coding recommendations) http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=153254#153254 [2005-08-05 16:27:54] ast at gmx dot ch Description: Abstract: --- PHP 4.4.0 shows a "Notice: Only variable references should be returned by reference in ..." Notice when it shouldn't. The bug can only be reproduced with PHP 4.4.0. And it can only be reproduced on a few systems, on most it returns the expected result (all test platforms had error_reporting(E_ALL);). Furthermore, code that seems to be equivalent doesn't result in a Notice. And two different systems with almost the same setup don't show the same results. I couldn't isolate the bug further than this. Maybe it's a compile options issue, maybe it has to do with the scope of variables, I don't know. Disclaimer: --- You may think this is another bogus bug report for the return-by-reference / assign-by-reference / pass-by-reference Notices in PHP 4.4.0. But I'm quite sure it isn't. I've patched our framework and wrote some recommendations on how to code the right way: http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=32907 . But you don't need to follow this link. I just want to point out that this is a real issue. Details: --- Please take a look at the reproduce script. Reproduce code: --- http://dev.nei.ch/bugs/php440_notice_bug/php440_notice_bug_on_certain_platforms.phps Expected result: Expected result: PHP Version is: 4.4.0 no NOTICEs Actual result: -- Actual result: -- php version is: 4.4.0 Notice: Only variable references should be returned by reference in php440_notice_bug_on_certain_platforms.php on line 23 -- Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34012 [Opn->Fbk]: PHP segfaults when connecting to MySQL
ID: 34012 Updated by: [EMAIL PROTECTED] Reported By: bjorn dot malmberg at gmail dot com -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Debian Sarge 3.1 PHP Version: 4.4.0 New Comment: Could you test it on another machine (that uses something different than Sarge)? That would answer your question, obviuosly. Previous Comments: [2005-08-05 19:20:56] bjorn dot malmberg at gmail dot com Description: PHP segfaults on my Debian 3.1 machine when trying to connect to MySQL. MySQL version: 4.1.13-standard Apache version: 1.3.31 PHP version: 4.4.0 PHP configline: ./configure --with-mysql=/usr/local/mysql --enable-track-vars --enable-xslt --with-xslt-sablot --enable-mbstring --with-apxs=/etc/apache/bin/apxs --with-gettext=/usr/bin --enable-sockets --with-gd --with-jpeg-dir=/usr/lib --with-zlib-dir=/usr/include --with-imagick --enable-exif --enable-sockets --enable-posix --with-iconv Backtrace: #0 0x4010139b in mallopt () from /lib/libc.so.6 #1 0x4010015f in free () from /lib/libc.so.6 #2 0x4033179c in _efree (ptr=0x812ec1c) at /usr/src/php/php-4.4.0/Zend/zend_alloc.c:265 #3 0x40290e27 in _close_mysql_link (rsrc=0x812f344) at /usr/src/php/php-4.4.0/ext/mysql/php_mysql.c:297 #4 0x40343434 in list_entry_destructor (ptr=0x812f344) at /usr/src/php/php-4.4.0/Zend/zend_list.c:177 #5 0x403423c9 in zend_hash_apply_deleter (ht=0x40632680, p=0x812a73c) at /usr/src/php/php-4.4.0/Zend/zend_hash.c:611 #6 0x403424ef in zend_hash_graceful_reverse_destroy (ht=0x40632680) at /usr/src/php/php-4.4.0/Zend/zend_hash.c:677 #7 0x40343535 in zend_destroy_rsrc_list (ht=0x40632680) at /usr/src/php/php-4.4.0/Zend/zend_list.c:233 #8 0x40336d93 in shutdown_executor () at /usr/src/php/php-4.4.0/Zend/zend_execute_API.c:211 #9 0x4033e5cd in zend_deactivate () at /usr/src/php/php-4.4.0/Zend/zend.c:693 #10 0x40319085 in php_request_shutdown (dummy=0x0) at /usr/src/php/php-4.4.0/main/main.c:997 #11 0x40356475 in apache_php_module_main (r=0x8125b6c, display_source_mode=0) at /usr/src/php/php-4.4.0/sapi/apache/sapi_apache.c:60 #12 0x40356e02 in send_php (r=0x8125b6c, display_source_mode=0, filename=0x0) at /usr/src/php/php-4.4.0/sapi/apache/mod_php4.c:627 #13 0x40356e51 in send_parsed_php (r=0x8125b6c) at /usr/src/php/php-4.4.0/sapi/apache/mod_php4.c:642 #14 0x0807aad9 in ap_invoke_handler () #15 0x080912bc in process_request_internal () #16 0x08091326 in ap_process_request () #17 0x080879a0 in child_main () #18 0x08087b51 in make_child () #19 0x08087ccc in startup_children () #20 0x080883ed in standalone_main () #21 0x08088c5c in main () I guess this means that PHP doesn't like the version of libc that Sarge is using huh? Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=34012&edit=1
#33995 [Fbk->Opn]: wrong WARNING message
ID: 33995 User updated by: zxc at zmail dot ru Reported By: zxc at zmail dot ru -Status: Feedback +Status: Open Bug Type: FTP related Operating System: Win2000 SP4 PHP Version: 4.4.0 New Comment: sniper, I use 3 parameters: I have WARNING message (from "ftp_login()" function) if remote FTP server is FULL (many users etc.) But I must have boolean FALSE only from ftp_login() function in this case (without WARNING message), because I use prefix "@" before "ftp_login()". Previous Comments: [2005-08-04 22:12:22] [EMAIL PROTECTED] You have to provide a working script. The one here can not work: ftp_login() expects 3 parameters, not 2.. (and I can't reproduce this with a proper script, even if the server shows errors) [2005-08-04 19:59:47] zxc at zmail dot ru Tony, I has tried change a FTP server to something, but I show WARNING still. [2005-08-04 19:56:42] zxc at zmail dot ru Example of WARNING: -- Warning: ftp_login(): Too many users - please try again later. in /pub/home/hissite/ftpconnect.php on line 73 -- Why shows a WARNING message? I use a "@" prefix before "ftp_login()" function. >>> I must have boolean FALSE only, without this WARNING. [2005-08-04 15:18:54] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. What warning? Which FTP server do you use? How to reproduce it? Are you able to reproduce it if you change your FTP server to something else? [2005-08-04 15:09:13] zxc at zmail dot ru Description: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Reproduce code: --- Expected result: I have a WARNING message from ftp_login(), but I use a "@" with ftp_login() function. Function ftp_login() in this case must returns boolean FALSE only without WARNING. Actual result: -- empty screen -- Edit this bug report at http://bugs.php.net/?id=33995&edit=1
#34010 [Opn->WFx]: bundled sqlite version:2, pdo-sqlite:3
ID: 34010 Updated by: [EMAIL PROTECTED] Reported By: akorthaus at web dot de -Status: Open +Status: Wont fix Bug Type: SQLite related Operating System: Linux 2.4.31 (gentoo) PHP Version: 5.1.0b3 New Comment: I doubt that will change ever. If you want to use Sqlite 3 with ext/sqlite - use external SQLite library and configure PHP with --with-sqlite= option. Previous Comments: [2005-08-05 17:28:30] akorthaus at web dot de Description: If I install php with sqlite (and sqlite-utf8), I geht the following version: SQLite SQLite support enabled PECL Module version 2.0-dev $Id: sqlite.c,v 1.165 2005/06/17 16:42:53 sniper Exp $ SQLite Library 2.8.14 SQLite Encoding UTF-8 If I install pdo-sqlite, I get the following version: pdo_sqlite PDO Driver for SQLite 3.x enabled PECL Module version (bundled) 0.9 $Id: pdo_sqlite.c,v 1.10 2005/07/27 04:07:11 wez Exp $ SQLite Library 3.2.2 Would be great of the two versions could be more in sync, to make it possible to use both php-extensions with the same data-files. -- Edit this bug report at http://bugs.php.net/?id=34010&edit=1
#34012 [NEW]: PHP segfaults when connecting to MySQL
From: bjorn dot malmberg at gmail dot com Operating system: Debian Sarge 3.1 PHP version: 4.4.0 PHP Bug Type: MySQL related Bug description: PHP segfaults when connecting to MySQL Description: PHP segfaults on my Debian 3.1 machine when trying to connect to MySQL. MySQL version: 4.1.13-standard Apache version: 1.3.31 PHP version: 4.4.0 PHP configline: ./configure --with-mysql=/usr/local/mysql --enable-track-vars --enable-xslt --with-xslt-sablot --enable-mbstring --with-apxs=/etc/apache/bin/apxs --with-gettext=/usr/bin --enable-sockets --with-gd --with-jpeg-dir=/usr/lib --with-zlib-dir=/usr/include --with-imagick --enable-exif --enable-sockets --enable-posix --with-iconv Backtrace: #0 0x4010139b in mallopt () from /lib/libc.so.6 #1 0x4010015f in free () from /lib/libc.so.6 #2 0x4033179c in _efree (ptr=0x812ec1c) at /usr/src/php/php-4.4.0/Zend/zend_alloc.c:265 #3 0x40290e27 in _close_mysql_link (rsrc=0x812f344) at /usr/src/php/php-4.4.0/ext/mysql/php_mysql.c:297 #4 0x40343434 in list_entry_destructor (ptr=0x812f344) at /usr/src/php/php-4.4.0/Zend/zend_list.c:177 #5 0x403423c9 in zend_hash_apply_deleter (ht=0x40632680, p=0x812a73c) at /usr/src/php/php-4.4.0/Zend/zend_hash.c:611 #6 0x403424ef in zend_hash_graceful_reverse_destroy (ht=0x40632680) at /usr/src/php/php-4.4.0/Zend/zend_hash.c:677 #7 0x40343535 in zend_destroy_rsrc_list (ht=0x40632680) at /usr/src/php/php-4.4.0/Zend/zend_list.c:233 #8 0x40336d93 in shutdown_executor () at /usr/src/php/php-4.4.0/Zend/zend_execute_API.c:211 #9 0x4033e5cd in zend_deactivate () at /usr/src/php/php-4.4.0/Zend/zend.c:693 #10 0x40319085 in php_request_shutdown (dummy=0x0) at /usr/src/php/php-4.4.0/main/main.c:997 #11 0x40356475 in apache_php_module_main (r=0x8125b6c, display_source_mode=0) at /usr/src/php/php-4.4.0/sapi/apache/sapi_apache.c:60 #12 0x40356e02 in send_php (r=0x8125b6c, display_source_mode=0, filename=0x0) at /usr/src/php/php-4.4.0/sapi/apache/mod_php4.c:627 #13 0x40356e51 in send_parsed_php (r=0x8125b6c) at /usr/src/php/php-4.4.0/sapi/apache/mod_php4.c:642 #14 0x0807aad9 in ap_invoke_handler () #15 0x080912bc in process_request_internal () #16 0x08091326 in ap_process_request () #17 0x080879a0 in child_main () #18 0x08087b51 in make_child () #19 0x08087ccc in startup_children () #20 0x080883ed in standalone_main () #21 0x08088c5c in main () I guess this means that PHP doesn't like the version of libc that Sarge is using huh? Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=34012&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34012&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34012&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34012&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34012&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34012&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34012&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34012&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34012&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34012&r=support Expected behavior: http://bugs.php.net/fix.php?id=34012&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34012&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34012&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34012&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34012&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34012&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34012&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34012&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34012&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34012&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34012&r=mysqlcfg
#34009 [Opn]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 4.4.0 New Comment: >From the reproduce script: Unexpected result oberserved on - http://nl01.pcextreme.nl/phpinfo.php (PHP 4.4.0, Linux Linux i686) - PHP 4.4.0 cgi hosted by Powweb.com, Apache/1.3.33 (Unix) FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7d PowWeb/1.1, FreeBSD clust05-www01.powweb.com 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Thu Ma i386 - Gentoo linux, PHP 4.4.0, apache 2, x86: http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_with_bug.html Correct behavior observed on - dozens / hundreds other servers, e.g. - Windows XP SP 2, PHP 4.4.0 cgi, apache 2, x86 - Gentoo linux, PHP 4.4.0, apache 2, x86: http://dev.nei.ch/bugs/php440_notice_bug/phpinfo_gentoo_without_bug.html (this is another gentoo box, completely unrelated to the other) Previous Comments: [2005-08-05 16:41:18] ast at gmx dot ch Sorry, the first link was incorrect :/ (Coding recommendations) http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=153254#153254 [2005-08-05 16:27:54] ast at gmx dot ch Description: Abstract: --- PHP 4.4.0 shows a "Notice: Only variable references should be returned by reference in ..." Notice when it shouldn't. The bug can only be reproduced with PHP 4.4.0. And it can only be reproduced on a few systems, on most it returns the expected result (all test platforms had error_reporting(E_ALL);). Furthermore, code that seems to be equivalent doesn't result in a Notice. And two different systems with almost the same setup don't show the same results. I couldn't isolate the bug further than this. Maybe it's a compile options issue, maybe it has to do with the scope of variables, I don't know. Disclaimer: --- You may think this is another bogus bug report for the return-by-reference / assign-by-reference / pass-by-reference Notices in PHP 4.4.0. But I'm quite sure it isn't. I've patched our framework and wrote some recommendations on how to code the right way: http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=32907 . But you don't need to follow this link. I just want to point out that this is a real issue. Details: --- Please take a look at the reproduce script. Reproduce code: --- http://dev.nei.ch/bugs/php440_notice_bug/php440_notice_bug_on_certain_platforms.phps Expected result: Expected result: PHP Version is: 4.4.0 no NOTICEs Actual result: -- Actual result: -- php version is: 4.4.0 Notice: Only variable references should be returned by reference in php440_notice_bug_on_certain_platforms.php on line 23 -- Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34011 [NEW]: variables_order not PHP_INI_ALL
From: [EMAIL PROTECTED] Operating system: all PHP version: 5CVS-2005-08-05 (dev) PHP Bug Type: *Configuration Issues Bug description: variables_order not PHP_INI_ALL Description: I'm not sure if this is a php bug or just a documentation bug. in http://lxr.php.net/source/php-src/main/main.c#305 variables_order is specified as beeing PHP_INI_ALL, so the manual also says that. But I've tested php 5.0.4 in cgi mode and php 5.1 as apache2 module an noone of them respect my ini_set() order, even if I type it in first line of the script (JIT is on). So, should the refering line be changed to INI_SYSTEM & documented the problem properly, or is it a real bug? -- Edit bug report at http://bugs.php.net/?id=34011&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34011&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34011&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34011&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34011&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34011&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34011&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34011&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34011&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34011&r=support Expected behavior: http://bugs.php.net/fix.php?id=34011&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34011&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34011&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34011&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34011&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34011&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34011&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34011&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34011&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34011&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34011&r=mysqlcfg
#34010 [NEW]: bundled sqlite version:2, pdo-sqlite:3
From: akorthaus at web dot de Operating system: Linux 2.4.31 (gentoo) PHP version: 5.1.0b3 PHP Bug Type: SQLite related Bug description: bundled sqlite version:2, pdo-sqlite:3 Description: If I install php with sqlite (and sqlite-utf8), I geht the following version: SQLite SQLite support enabled PECL Module version 2.0-dev $Id: sqlite.c,v 1.165 2005/06/17 16:42:53 sniper Exp $ SQLite Library 2.8.14 SQLite Encoding UTF-8 If I install pdo-sqlite, I get the following version: pdo_sqlite PDO Driver for SQLite 3.x enabled PECL Module version (bundled) 0.9 $Id: pdo_sqlite.c,v 1.10 2005/07/27 04:07:11 wez Exp $ SQLite Library 3.2.2 Would be great of the two versions could be more in sync, to make it possible to use both php-extensions with the same data-files. -- Edit bug report at http://bugs.php.net/?id=34010&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34010&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34010&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34010&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34010&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34010&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34010&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34010&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34010&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34010&r=support Expected behavior: http://bugs.php.net/fix.php?id=34010&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34010&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34010&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34010&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34010&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34010&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34010&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34010&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34010&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34010&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34010&r=mysqlcfg
#33965 [Fbk->Opn]: NULL valued output parameters from stored procedures contain corrupt data
ID: 33965
User updated by: paul dot robinson at groupbc dot com
Reported By: paul dot robinson at groupbc dot com
-Status: Feedback
+Status: Open
Bug Type: MSSQL related
Operating System: Linux (RHEL 4)
PHP Version: 5.0.4
New Comment:
Patch against php_mssql.c CVS version 1.149 can be found here:
http://cobweb.businesscollaborator.com/pdr/33965.patch
Rationale behind the patch was discussed here:
http://lists.ibiblio.org/pipermail/freetds/2005q3/018851.html
This has been verified to work with FreeTDS releases _after_ 0.63.
Without this patch output parameters that should be null will simply
read random data.
Previous Comments:
[2005-08-02 19:12:53] [EMAIL PROTECTED]
Provide patches in unified diff format (diff -u) and against PHP CVS
HEAD (we're not likely to release any 5.0.x versions anymore). Put the
diffs somewhere were people can download it and put the URLs here.
[2005-08-02 18:50:33] paul dot robinson at groupbc dot com
Patches suggested are against Snapshot:
php5-STABLE-200508021038.tar.gz
Although I haven't actually built an example using that snapshot today
I have looked at the code which since it is unchanged would seem to
exhibit the same problem.
[2005-08-02 18:34:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-02 14:01:38] paul dot robinson at groupbc dot com
Description:
MS SQL Server 2000, FreeTDS 0.63
Output parameters from a stored procedure call contain corrupt data
when the result should be NULL. Its particularly noticable for variable
length strings as output looks as though it just reads from a random
pointer until it find a \0 !
No test is done on whether the output is NULL or not.
Diff below shows proposed change to fix this.
NOTE: This calls a function dbretisnull that is not currently
implemented in the FreeTDS package but has been submitted as a proposed
change.
19c19
< /* $Id: php_mssql.c,v 1.137.2.9 2005/04/12 17:46:06 fmk Exp $ */
---
> /* $Id: php_mssql.c,v 1.137.2.8 2005/02/25 23:25:33 fmk Exp $ */
324,326d323
< #ifndef HAVE_FREETDS
< dbwinexit();
< #else
328d324
< #endif
978c974
< int i, num_rets, type;
---
> int i, num_rets, type, is_null;
992,1019c988,1022
< switch (type) {
< case SQLBIT:
< case SQLINT1:
< case SQLINT2:
< case SQLINT4:
<
convert_to_long_ex(&bind->zval);
< /* FIXME this
works only on little endian machine !!! */
<
Z_LVAL_P(bind->zval) = *((int *)(dbretdata(mssql_ptr->link,i)));
< break;
<
< case SQLFLT4:
< case SQLFLT8:
< case SQLFLTN:
< case SQLMONEY4:
< case SQLMONEY:
< case SQLMONEYN:
<
convert_to_double_ex(&bind->zval);
<
Z_DVAL_P(bind->zval) = *((double *)(dbretdata(mssql_ptr->link,i)));
< break;
<
< case SQLCHAR:
< case SQLVARCHAR:
< case SQLTEXT:
<
convert_to_string_ex(&bind->zval);
<
Z_STRLEN_P(bind->zval) = dbretlen(mssql_ptr->link,i);
<
Z_STRVAL_P(bind->zval) =
estrndup(dbretdata(mssql_ptr->link,i),Z_STRLEN_P(bind->zval));
< break;
< /* TODO binary */
---
> /* Test column value for null
flag and set value as required */
> is_null =
dbretisnull(mssql_ptr->link, i);
> if (is_null) {
> ZVAL_NULL(bind->zval);
>
#33963 [Fbk->Opn]: Binding some stored procedure parameters fails
ID: 33963
User updated by: paul dot robinson at groupbc dot com
Reported By: paul dot robinson at groupbc dot com
-Status: Feedback
+Status: Open
Bug Type: MSSQL related
Operating System: Linux (RHEL 4)
PHP Version: 5.0.4
New Comment:
Patch against php_mssql.c CVS version 1.149 can be found here:
http://cobweb.businesscollaborator.com/pdr/33963.patch
The values of maxlen and datalen set here have been verified to work
with FreeTDS 0.63 and the latest CVS code as of 5/8/2005.
Previous Comments:
[2005-08-02 19:13:45] [EMAIL PROTECTED]
Provide patches in unified diff format (diff -u) and against PHP CVS
HEAD (we're not likely to release any 5.0.x versions anymore). Put the
diffs somewhere were people can download it and put the URLs here.
[2005-08-02 18:51:03] paul dot robinson at groupbc dot com
Patches suggested are against Snapshot:
php5-STABLE-200508021038.tar.gz
Although I haven't actually built an example using that snapshot today
I have looked at the code which since it is unchanged would seem to
exhibit the same problem.
[2005-08-02 18:34:32] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-02 13:39:23] paul dot robinson at groupbc dot com
Description:
Using FreeTDS 0.63 (latest stable release), calling mssql_bind can fail
due to the restrictions placed on parameters by the dbrpcparam function
from FreeTDS.
One specific example is an input parameter must have maxlen==-1. With
the code as is in PHP 5.0.4 a NULL valued variable length type input
parameter will always have maxlen==0 thereby always failing.
Diff below shows changes to ext/mssql/php_mssql.c that address this
parameter mismatch.
2025,2026c2025,2029
< maxlen=0;
< datalen=0;
---
> datalen = 0;
> if (is_output)
> maxlen = -1;
> else
> maxlen = -1;
2030d2032
< datalen=Z_STRLEN_PP(var);
2031a2034,2046
>
> if (is_output) {
> if ((maxlen > 0 ) && (maxlen < 256))
> datalen = maxlen;
> else {
> maxlen = 255;
> datalen = 255;
> }
> }
> else {
> maxlen = -1;
> datalen=Z_STRLEN_PP(var);
> }
Reproduce code:
---
mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR);
or
mssql_bind($query, "@varchar1", $varchar1, SQLVARCHAR, false, true,
57);
Expected result:
Sucessfully bind input variable.
Actual result:
--
"Unable to set parameter"
i.e. FAIL is returned by the call to dbrpcparam in
PHP_FUNCTION(mssql_bind).
--
Edit this bug report at http://bugs.php.net/?id=33963&edit=1
#34009 [Opn]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
ID: 34009 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 4.4.0 New Comment: Sorry, the first link was incorrect :/ (Coding recommendations) http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=153254#153254 Previous Comments: [2005-08-05 16:27:54] ast at gmx dot ch Description: Abstract: --- PHP 4.4.0 shows a "Notice: Only variable references should be returned by reference in ..." Notice when it shouldn't. The bug can only be reproduced with PHP 4.4.0. And it can only be reproduced on a few systems, on most it returns the expected result (all test platforms had error_reporting(E_ALL);). Furthermore, code that seems to be equivalent doesn't result in a Notice. And two different systems with almost the same setup don't show the same results. I couldn't isolate the bug further than this. Maybe it's a compile options issue, maybe it has to do with the scope of variables, I don't know. Disclaimer: --- You may think this is another bogus bug report for the return-by-reference / assign-by-reference / pass-by-reference Notices in PHP 4.4.0. But I'm quite sure it isn't. I've patched our framework and wrote some recommendations on how to code the right way: http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=32907 . But you don't need to follow this link. I just want to point out that this is a real issue. Details: --- Please take a look at the reproduce script. Reproduce code: --- http://dev.nei.ch/bugs/php440_notice_bug/php440_notice_bug_on_certain_platforms.phps Expected result: Expected result: PHP Version is: 4.4.0 no NOTICEs Actual result: -- Actual result: -- php version is: 4.4.0 Notice: Only variable references should be returned by reference in php440_notice_bug_on_certain_platforms.php on line 23 -- Edit this bug report at http://bugs.php.net/?id=34009&edit=1
#34009 [NEW]: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't
From: ast at gmx dot ch Operating system: Gentoo Linux PHP version: 4.4.0 PHP Bug Type: Scripting Engine problem Bug description: PHP 4.4.0 shows on some platforms a return by reference Notice,but it shouldn't Description: Abstract: --- PHP 4.4.0 shows a "Notice: Only variable references should be returned by reference in ..." Notice when it shouldn't. The bug can only be reproduced with PHP 4.4.0. And it can only be reproduced on a few systems, on most it returns the expected result (all test platforms had error_reporting(E_ALL);). Furthermore, code that seems to be equivalent doesn't result in a Notice. And two different systems with almost the same setup don't show the same results. I couldn't isolate the bug further than this. Maybe it's a compile options issue, maybe it has to do with the scope of variables, I don't know. Disclaimer: --- You may think this is another bogus bug report for the return-by-reference / assign-by-reference / pass-by-reference Notices in PHP 4.4.0. But I'm quite sure it isn't. I've patched our framework and wrote some recommendations on how to code the right way: http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=32907 . But you don't need to follow this link. I just want to point out that this is a real issue. Details: --- Please take a look at the reproduce script. Reproduce code: --- http://dev.nei.ch/bugs/php440_notice_bug/php440_notice_bug_on_certain_platforms.phps Expected result: Expected result: PHP Version is: 4.4.0 no NOTICEs Actual result: -- Actual result: -- php version is: 4.4.0 Notice: Only variable references should be returned by reference in php440_notice_bug_on_certain_platforms.php on line 23 -- Edit bug report at http://bugs.php.net/?id=34009&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34009&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34009&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34009&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34009&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34009&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34009&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34009&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34009&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34009&r=support Expected behavior: http://bugs.php.net/fix.php?id=34009&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34009&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34009&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34009&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34009&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34009&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34009&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34009&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34009&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34009&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34009&r=mysqlcfg
#34004 [Fbk->Opn]: an fatal error on php5ts.dll
ID: 34004
User updated by: kenji at neojin dot com
Reported By: kenji at neojin dot com
-Status: Feedback
+Status: Open
Bug Type: *Web Server problem
Operating System: windows xp
PHP Version: 5.0.4
New Comment:
i find the bug
this fonction create the fatal error with apache and php5ts.dll on my
computer
i delete her and all it's ok
when i replace this fonction => fatal error
i hope that you help
Previous Comments:
[2005-08-05 13:47:48] [EMAIL PROTECTED]
Please provide a short but *COMPLETE* reproduce script, so we can
copy/paste it and reproduce your problem.
Thank you.
[2005-08-05 13:42:23] kenji at neojin dot com
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is
alaways the same
Reproduce code:
---
Send_Query("SELECT * FROM file_xml");
if($objet = $Bdd -> get_object($result)){
$id_file = $objet -> id_file_xml;
}
if($id_file<>''){
if(file_exists('../../cache/liste'.$id_file.'.xml')){
@unlink('../../cache/liste'.$id_file.'.xml');
}
$Bdd -> Send_Query("DELETE FROM file_xml");
}
$Bdd -> Send_Query("INSERT INTO file_xml (date,heure)
VALUES
(now(),now())");
$id_xml = $Bdd -> insert_id();
/*$xml = '';*/
$xml .= '';
$i = 1;
$result = $Bdd -> Send_Query("SELECT * FROM maisons");
while($objet = $Bdd -> get_object($result)){
$nom = stripslashes($objet -> m_nom);
$xml .= '
';
}
$xml .= '';
$handle = fopen('../../cache/liste'.$id_xml.'.xml',
'w+');
fwrite($handle, $xml);
fclose($handle);
?>
hello
the problem is the script is in my own develeppement server offline
i have uninstall and reinstall windows and just install apache / php
for test but the result is same witdh the script
if i comment this script all it s ok
i don't understand why this bug
i tried this script under another server width apache 1.3.23 and php
5.0.4 and it s ok
my computer :
p4 3.0
2 go ram
ati x700 pro
win xp sp2
the problem can be width ram ?
sorry another script are ok
just this not works and several error width windows appear
ps : sorry for my english
[2005-08-05 10:45:49] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-08-05 10:44:35] kenji at neojin dot com
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is
alaways the same
Reproduce code:
---
function sansaccent($chaine){
return
strtr($chaine,'àâäåãáÂÄÀÅÃÁæÆçÇéèêëÉÊËÈïîìíÏÎÌÍñÑöôóòõÓÔÖÒÕùûüúÜÛÙÚÿ','aaccnnooy');
}
//creation du fichier xml
$result = $Bdd -> Send_Query("SELECT * FROM file_xml");
if($objet = $Bdd -> get_object($result)){
#34008 [NEW]: Make file error
From: ljanda at checkstop dot com Operating system: SCO 5.05 PHP version: 4.4.0 PHP Bug Type: *Configuration Issues Bug description: Make file error Description: Simple problem in configure: ./configure --without-mysql --with-informix --with-apache=../apache_1.3.19 --ena ble-shared --enable-track-vars Adding the Informix puts a line into make file without tab (\t) and therefore the make fails. Looked and makefile and sure enough, the line was left justified, put the tab in and got it to work. Reproduce code: --- install-cli: $(SAPI_CLI_PATH) @echo "Installing PHP CLI binary:$(INSTALL_ROOT)$(bindir)/" @$(INSTALL_CLI) @echo "Installing PHP CLI man page: $(INSTALL_ROOT)$(mandir)/man1/" @$(mkinstalldirs) $(INSTALL_ROOT)$(mandir)/man1 @$(INSTALL_DATA) sapi/cli/php.1 $(INSTALL_ROOT)$(mandir)/man1/php.1 /*** this line needs a tab OVERALL_TARGET += /u/leroy/php-4.4.0/ext/informix/ifx.c /u/leroy/php- Expected result: make error -- Edit bug report at http://bugs.php.net/?id=34008&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34008&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34008&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34008&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34008&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34008&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34008&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34008&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34008&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34008&r=support Expected behavior: http://bugs.php.net/fix.php?id=34008&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34008&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34008&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34008&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34008&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34008&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34008&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34008&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34008&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34008&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34008&r=mysqlcfg
#34007 [NEW]: cURL compilation fails with GCC 4.x
From: [EMAIL PROTECTED] Operating system: GNU/Linux PHP version: 5CVS-2005-08-05 (dev) PHP Bug Type: Compile Failure Bug description: cURL compilation fails with GCC 4.x Description: Building the latest snapshot of PHP 5.1 with cURL support enabled fails. This seems to be a problem with GCC 4.x only, because it builds fine with GCC 3.3. $ gcc --version gcc (GCC) 4.0.2 20050725 (prerelease) (Debian 4.0.1-3) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Actual result: -- /home/martin/src/php5-200508051030/ext/curl/interface.c: In function 'zif_curl_init': /home/martin/src/php5-200508051030/ext/curl/interface.c:829: error: invalid lvalue in assignment /home/martin/src/php5-200508051030/ext/curl/interface.c: In function 'zif_curl_copy_handle': /home/martin/src/php5-200508051030/ext/curl/interface.c:890: error: invalid lvalue in assignment make: *** [ext/curl/interface.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=34007&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34007&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34007&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34007&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34007&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34007&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34007&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34007&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34007&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34007&r=support Expected behavior: http://bugs.php.net/fix.php?id=34007&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34007&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34007&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34007&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34007&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34007&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34007&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34007&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34007&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34007&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34007&r=mysqlcfg
#34003 [Bgs]: bugreports feedback
ID: 34003 User updated by: de at nospam dot net Reported By: de at nospam dot net Status: Bogus Bug Type:*General Issues PHP Version: 5.1.0b3 New Comment: No, it is not for whining... but it is not meant to be an automated "no bug" system either... it is for truly CONSIDERING the bug reports! If you don't want people reporting, just mention it and you will save a lot of people spending their time. Previous Comments: [2005-08-05 09:12:01] [EMAIL PROTECTED] This bug system is not meant for whining. No bug -> bogus. [2005-08-05 05:20:05] de at nospam dot net Description: I hope the targeted audience is reading this before removing it... I know you are busy doing things... but I think it would be nice to consider the reports a bit more carefully than just writing "this is not a bug"... like it was for example done in #33679 (but I saw it in a few other reports as well). But see #33558 ... if I am not completly wrong, there at least calling a function which returned a reference were eventually accepted to be a bug and fixed. (It does not tell anything about the other two versions though) Which means #33679 was not completly "Bogus". And if you were asking me as a developer (making use of some programming languages), what was in #33679 expected is general practise of OOP. And to me it seemed, that this is something PHP want to move toward. -- Edit this bug report at http://bugs.php.net/?id=34003&edit=1
#33871 [Fbk]: No daylight savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
Status: Feedback
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
This is datas from your system (or the version you use). The problem
with windows is that there is many different datas in each single
product version.
--Pierre
Previous Comments:
[2005-08-05 13:55:21] [EMAIL PROTECTED]
A better program would be:
#include
#include
main () {
time_t t;
struct tm *tstruct;
tstruct = localtime ((time(&t), &t));
printf("TZ=%s TZDST=%s is_dst:%d\n", _tzname[0], _tzname[1],
tstruct->tm_isdst);
}
is_dst is 0 if DST isn't in effect, or positive otherwise.
Although you cannot get the precise tz info, you can get the timezone
offset with ease.
there is a nice example here:
http://msdn.microsoft.com/library/en-us/vclib/html/_crt_time.asp but I
can't test it, because cygwin's win32 api doesn't export some required
structures (and I didn't installed MSVC yet).
[2005-08-05 13:36:05] [EMAIL PROTECTED]
to derick:
actually its not that difficult to guess the timezone on windows (with
the comming winfx api will be even easier).
After some research on the web and some testing:
#include
main () {
time_t t;
localtime ((time(&t), &t)); // fill the _tzname var
printf("TZ=%s TZDST=%s\n", _tzname[0], _tzname[1]);
}
with GMT outputs:
TZ=GMTST TZDST=GMTDT
_tzname[0] is the timezone abbr name. _tzname[1] is filled if the
current timezone has DST changes.
more testing:
Pacific time:
TZ=PST TZDST=PDT
Central time:
TZ=CST TZDST=CDT
Brasilia:
TZ=ESAST TZDST=ESADT
Brisbane:
TZ=EAST TZDST=
The problem here is that our DB doesn't have these abbreviations. But
with some trialing we could all tz settings that windows uses and link
them to the main db.
[2005-08-05 13:30:11] joerg dot klein at ifsam dot lu
hi
it seems that I have a related problem:
I am on GMT+1
for the following example the system time is 11:00
date("H:i");
=> 09:00
set system time-zone to GMT(+0)
date("H:i");
=> 09:00
set system time to 10:00
date("H:i");
=> 08:00
It seems that php don't have the correct timezone. This error occurs
since 5.1.0b3.
My box runs on win2000SP4 with the latest snapshot.
[2005-08-05 12:53:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Sorry, but I've tested on windows and it works perfectly. Are you sure
you are using an up-to-date snapshot? And that means PHP 5.1.0 beta 3
is old...
[2005-08-04 17:01:09] jeremy at techtrav dot com
By the way I do have E_ALL turned on, on my machine. After all I don't
run my windows box with PHP in production. I use my windows box for
development. Our PHP production runs on OpenBSD servers.
I don't quite understand this comment of yours:
"Now, if we can find a way how PHP can guess the correct timezone from
your windows box "
PHP 5.0.4 reads my TZ perfectly and gives you the expected result. Why
would PHP 5.1.X not be able to?
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Fbk]: No daylight savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
Status: Feedback
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
A better program would be:
#include
#include
main () {
time_t t;
struct tm *tstruct;
tstruct = localtime ((time(&t), &t));
printf("TZ=%s TZDST=%s is_dst:%d\n", _tzname[0], _tzname[1],
tstruct->tm_isdst);
}
is_dst is 0 if DST isn't in effect, or positive otherwise.
Although you cannot get the precise tz info, you can get the timezone
offset with ease.
there is a nice example here:
http://msdn.microsoft.com/library/en-us/vclib/html/_crt_time.asp but I
can't test it, because cygwin's win32 api doesn't export some required
structures (and I didn't installed MSVC yet).
Previous Comments:
[2005-08-05 13:36:05] [EMAIL PROTECTED]
to derick:
actually its not that difficult to guess the timezone on windows (with
the comming winfx api will be even easier).
After some research on the web and some testing:
#include
main () {
time_t t;
localtime ((time(&t), &t)); // fill the _tzname var
printf("TZ=%s TZDST=%s\n", _tzname[0], _tzname[1]);
}
with GMT outputs:
TZ=GMTST TZDST=GMTDT
_tzname[0] is the timezone abbr name. _tzname[1] is filled if the
current timezone has DST changes.
more testing:
Pacific time:
TZ=PST TZDST=PDT
Central time:
TZ=CST TZDST=CDT
Brasilia:
TZ=ESAST TZDST=ESADT
Brisbane:
TZ=EAST TZDST=
The problem here is that our DB doesn't have these abbreviations. But
with some trialing we could all tz settings that windows uses and link
them to the main db.
[2005-08-05 13:30:11] joerg dot klein at ifsam dot lu
hi
it seems that I have a related problem:
I am on GMT+1
for the following example the system time is 11:00
date("H:i");
=> 09:00
set system time-zone to GMT(+0)
date("H:i");
=> 09:00
set system time to 10:00
date("H:i");
=> 08:00
It seems that php don't have the correct timezone. This error occurs
since 5.1.0b3.
My box runs on win2000SP4 with the latest snapshot.
[2005-08-05 12:53:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Sorry, but I've tested on windows and it works perfectly. Are you sure
you are using an up-to-date snapshot? And that means PHP 5.1.0 beta 3
is old...
[2005-08-04 17:01:09] jeremy at techtrav dot com
By the way I do have E_ALL turned on, on my machine. After all I don't
run my windows box with PHP in production. I use my windows box for
development. Our PHP production runs on OpenBSD servers.
I don't quite understand this comment of yours:
"Now, if we can find a way how PHP can guess the correct timezone from
your windows box "
PHP 5.0.4 reads my TZ perfectly and gives you the expected result. Why
would PHP 5.1.X not be able to?
[2005-08-04 16:55:55] jeremy at techtrav dot com
okay I figured out how to set my time zone.
I ran the following code in PHP 5.0.4 and PHP 5.1.X and recieved the
same result
putenv("TZ=US/Central");
echo date('r', (strtotime('oct 25')+(86400*6)));
This would mean the bug is simply that PHP5.1.X is not looking at the
time zone on the local machine.
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#34004 [Opn->Fbk]: an fatal error on php5ts.dll
ID: 34004
Updated by: [EMAIL PROTECTED]
Reported By: kenji at neojin dot com
-Status: Open
+Status: Feedback
Bug Type: *Web Server problem
Operating System: windows xp
PHP Version: 5.0.4
New Comment:
Please provide a short but *COMPLETE* reproduce script, so we can
copy/paste it and reproduce your problem.
Thank you.
Previous Comments:
[2005-08-05 13:42:23] kenji at neojin dot com
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is
alaways the same
Reproduce code:
---
Send_Query("SELECT * FROM file_xml");
if($objet = $Bdd -> get_object($result)){
$id_file = $objet -> id_file_xml;
}
if($id_file<>''){
if(file_exists('../../cache/liste'.$id_file.'.xml')){
@unlink('../../cache/liste'.$id_file.'.xml');
}
$Bdd -> Send_Query("DELETE FROM file_xml");
}
$Bdd -> Send_Query("INSERT INTO file_xml (date,heure)
VALUES
(now(),now())");
$id_xml = $Bdd -> insert_id();
/*$xml = '';*/
$xml .= '';
$i = 1;
$result = $Bdd -> Send_Query("SELECT * FROM maisons");
while($objet = $Bdd -> get_object($result)){
$nom = stripslashes($objet -> m_nom);
$xml .= '
';
}
$xml .= '';
$handle = fopen('../../cache/liste'.$id_xml.'.xml',
'w+');
fwrite($handle, $xml);
fclose($handle);
?>
hello
the problem is the script is in my own develeppement server offline
i have uninstall and reinstall windows and just install apache / php
for test but the result is same witdh the script
if i comment this script all it s ok
i don't understand why this bug
i tried this script under another server width apache 1.3.23 and php
5.0.4 and it s ok
my computer :
p4 3.0
2 go ram
ati x700 pro
win xp sp2
the problem can be width ram ?
sorry another script are ok
just this not works and several error width windows appear
ps : sorry for my english
[2005-08-05 10:45:49] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-08-05 10:44:35] kenji at neojin dot com
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is
alaways the same
Reproduce code:
---
function sansaccent($chaine){
return
strtr($chaine,'àâäåãáÂÄÀÅÃÁæÆçÇéèêëÉÊËÈïîìíÏÎÌÍñÑöôóòõÓÔÖÒÕùûüúÜÛÙÚÿ','aaccnnooy');
}
//creation du fichier xml
$result = $Bdd -> Send_Query("SELECT * FROM file_xml");
if($objet = $Bdd -> get_object($result)){
$id_file = $objet -> id_file_xml;
}
if($id_file<>''){
if(file_exists('../../cache/liste'.$id_file.'.xml')){
@unlink('../../cache/liste'.$id_file.'.xml');
#34004 [Fbk->Opn]: an fatal error on php5ts.dll
ID: 34004
User updated by: kenji at neojin dot com
Reported By: kenji at neojin dot com
-Status: Feedback
+Status: Open
Bug Type: *Web Server problem
Operating System: windows xp
PHP Version: 5.0.4
New Comment:
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is
alaways the same
Reproduce code:
---
Send_Query("SELECT * FROM file_xml");
if($objet = $Bdd -> get_object($result)){
$id_file = $objet -> id_file_xml;
}
if($id_file<>''){
if(file_exists('../../cache/liste'.$id_file.'.xml')){
@unlink('../../cache/liste'.$id_file.'.xml');
}
$Bdd -> Send_Query("DELETE FROM file_xml");
}
$Bdd -> Send_Query("INSERT INTO file_xml (date,heure)
VALUES
(now(),now())");
$id_xml = $Bdd -> insert_id();
/*$xml = '';*/
$xml .= '';
$i = 1;
$result = $Bdd -> Send_Query("SELECT * FROM maisons");
while($objet = $Bdd -> get_object($result)){
$nom = stripslashes($objet -> m_nom);
$xml .= '
';
}
$xml .= '';
$handle = fopen('../../cache/liste'.$id_xml.'.xml',
'w+');
fwrite($handle, $xml);
fclose($handle);
?>
hello
the problem is the script is in my own develeppement server offline
i have uninstall and reinstall windows and just install apache / php
for test but the result is same witdh the script
if i comment this script all it s ok
i don't understand why this bug
i tried this script under another server width apache 1.3.23 and php
5.0.4 and it s ok
my computer :
p4 3.0
2 go ram
ati x700 pro
win xp sp2
the problem can be width ram ?
sorry another script are ok
just this not works and several error width windows appear
ps : sorry for my english
Previous Comments:
[2005-08-05 10:45:49] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-08-05 10:44:35] kenji at neojin dot com
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is
alaways the same
Reproduce code:
---
function sansaccent($chaine){
return
strtr($chaine,'àâäåãáÂÄÀÅÃÁæÆçÇéèêëÉÊËÈïîìíÏÎÌÍñÑöôóòõÓÔÖÒÕùûüúÜÛÙÚÿ','aaccnnooy');
}
//creation du fichier xml
$result = $Bdd -> Send_Query("SELECT * FROM file_xml");
if($objet = $Bdd -> get_object($result)){
$id_file = $objet -> id_file_xml;
}
if($id_file<>''){
if(file_exists('../../cache/liste'.$id_file.'.xml')){
@unlink('../../cache/liste'.$id_file.'.xml');
}
$Bdd -> Send_Query("DELETE FROM file_xml");
}
$Bdd -> Send_Query("INSERT INTO file_xml (date,heure)
VALUE
#34005 [Asn]: ocipasswordchange() fails
ID: 34005 User updated by: uherj at avx dot cz Reported By: uherj at avx dot cz Status: Assigned Bug Type: OCI8 related Operating System: WinNT PHP Version: 4.4.0 Assigned To: tony2001 New Comment: this bug shows only when user account return warning: Warning: ocilogon(): OCISessionBegin: OCI_SUCCESS_WITH_INFO: ORA-28002: the password will expire within 10 day Previous Comments: [2005-08-05 10:54:46] [EMAIL PROTECTED] FYI ocipasswordchange() passes correct string to OCI funcs. No idea why it fails. [2005-08-05 10:51:19] uherj at avx dot cz Description: after sucessful connecting retuns function ocipasswordchange() this output: Warning: ocipasswordchange(): OCIPasswordChange: ORA-28008: invalid old password Password is not changed and ocierror() is empty. With ociinternaldebug(1) do not returns any messaged related to change of passwords. --- Oracle versions are: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production PL/SQL Release 9.2.0.4.0 - Production CORE 9.2.0.3.0 Production TNS for VMS: Version 9.2.0.4.0 - Production NLSRTL Version 9.2.0.4.0 - Production PHP:windows binary distribution, CGI Reproduce code: --- $con=ocilogon($user,$password,$dbstring); $ch=ocipasswordchange($con, $user, $password, $password_new1); Note: same behaviour when passed wrong password: $ch=ocipasswordchange($con, $user, "blahblah", $password_new1); Expected result: change password or return relevant error from Oracle Actual result: -- do not change password, because PHP function ocipasswordchange() passed wrong string to Oracle function OCIPasswordChange -- Edit this bug report at http://bugs.php.net/?id=34005&edit=1
#33871 [Fbk]: No daylight savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
Status: Feedback
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
to derick:
actually its not that difficult to guess the timezone on windows (with
the comming winfx api will be even easier).
After some research on the web and some testing:
#include
main () {
time_t t;
localtime ((time(&t), &t)); // fill the _tzname var
printf("TZ=%s TZDST=%s\n", _tzname[0], _tzname[1]);
}
with GMT outputs:
TZ=GMTST TZDST=GMTDT
_tzname[0] is the timezone abbr name. _tzname[1] is filled if the
current timezone has DST changes.
more testing:
Pacific time:
TZ=PST TZDST=PDT
Central time:
TZ=CST TZDST=CDT
Brasilia:
TZ=ESAST TZDST=ESADT
Brisbane:
TZ=EAST TZDST=
The problem here is that our DB doesn't have these abbreviations. But
with some trialing we could all tz settings that windows uses and link
them to the main db.
Previous Comments:
[2005-08-05 13:30:11] joerg dot klein at ifsam dot lu
hi
it seems that I have a related problem:
I am on GMT+1
for the following example the system time is 11:00
date("H:i");
=> 09:00
set system time-zone to GMT(+0)
date("H:i");
=> 09:00
set system time to 10:00
date("H:i");
=> 08:00
It seems that php don't have the correct timezone. This error occurs
since 5.1.0b3.
My box runs on win2000SP4 with the latest snapshot.
[2005-08-05 12:53:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Sorry, but I've tested on windows and it works perfectly. Are you sure
you are using an up-to-date snapshot? And that means PHP 5.1.0 beta 3
is old...
[2005-08-04 17:01:09] jeremy at techtrav dot com
By the way I do have E_ALL turned on, on my machine. After all I don't
run my windows box with PHP in production. I use my windows box for
development. Our PHP production runs on OpenBSD servers.
I don't quite understand this comment of yours:
"Now, if we can find a way how PHP can guess the correct timezone from
your windows box "
PHP 5.0.4 reads my TZ perfectly and gives you the expected result. Why
would PHP 5.1.X not be able to?
[2005-08-04 16:55:55] jeremy at techtrav dot com
okay I figured out how to set my time zone.
I ran the following code in PHP 5.0.4 and PHP 5.1.X and recieved the
same result
putenv("TZ=US/Central");
echo date('r', (strtotime('oct 25')+(86400*6)));
This would mean the bug is simply that PHP5.1.X is not looking at the
time zone on the local machine.
[2005-08-04 16:54:58] [EMAIL PROTECTED]
That function is only there in the snapshots, please try that instead.
http://snaps.php.net (and pick latest cvs (5.1-dev) there).
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Com]: No daylight savings time
ID: 33871
Comment by: joerg dot klein at ifsam dot lu
Reported By: jeremy at techtrav dot com
Status: Feedback
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
hi
it seems that I have a related problem:
I am on GMT+1
for the following example the system time is 11:00
date("H:i");
=> 09:00
set system time-zone to GMT(+0)
date("H:i");
=> 09:00
set system time to 10:00
date("H:i");
=> 08:00
It seems that php don't have the correct timezone. This error occurs
since 5.1.0b3.
My box runs on win2000SP4 with the latest snapshot.
Previous Comments:
[2005-08-05 12:53:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Sorry, but I've tested on windows and it works perfectly. Are you sure
you are using an up-to-date snapshot? And that means PHP 5.1.0 beta 3
is old...
[2005-08-04 17:01:09] jeremy at techtrav dot com
By the way I do have E_ALL turned on, on my machine. After all I don't
run my windows box with PHP in production. I use my windows box for
development. Our PHP production runs on OpenBSD servers.
I don't quite understand this comment of yours:
"Now, if we can find a way how PHP can guess the correct timezone from
your windows box "
PHP 5.0.4 reads my TZ perfectly and gives you the expected result. Why
would PHP 5.1.X not be able to?
[2005-08-04 16:55:55] jeremy at techtrav dot com
okay I figured out how to set my time zone.
I ran the following code in PHP 5.0.4 and PHP 5.1.X and recieved the
same result
putenv("TZ=US/Central");
echo date('r', (strtotime('oct 25')+(86400*6)));
This would mean the bug is simply that PHP5.1.X is not looking at the
time zone on the local machine.
[2005-08-04 16:54:58] [EMAIL PROTECTED]
That function is only there in the snapshots, please try that instead.
http://snaps.php.net (and pick latest cvs (5.1-dev) there).
[2005-08-04 16:53:03] [EMAIL PROTECTED]
Now, if we can find a way how PHP can guess the correct timezone from
your windows box (like it can do on most unices) that would be nice -
but I think it's quite impossible.
BTW, if you use error_reporting(E_ALL) you'd have gotten a warning
about this...
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33871 [Asn->Fbk]: No daylight savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
-Status: Assigned
+Status: Feedback
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Sorry, but I've tested on windows and it works perfectly. Are you sure
you are using an up-to-date snapshot? And that means PHP 5.1.0 beta 3
is old...
Previous Comments:
[2005-08-04 17:01:09] jeremy at techtrav dot com
By the way I do have E_ALL turned on, on my machine. After all I don't
run my windows box with PHP in production. I use my windows box for
development. Our PHP production runs on OpenBSD servers.
I don't quite understand this comment of yours:
"Now, if we can find a way how PHP can guess the correct timezone from
your windows box "
PHP 5.0.4 reads my TZ perfectly and gives you the expected result. Why
would PHP 5.1.X not be able to?
[2005-08-04 16:55:55] jeremy at techtrav dot com
okay I figured out how to set my time zone.
I ran the following code in PHP 5.0.4 and PHP 5.1.X and recieved the
same result
putenv("TZ=US/Central");
echo date('r', (strtotime('oct 25')+(86400*6)));
This would mean the bug is simply that PHP5.1.X is not looking at the
time zone on the local machine.
[2005-08-04 16:54:58] [EMAIL PROTECTED]
That function is only there in the snapshots, please try that instead.
http://snaps.php.net (and pick latest cvs (5.1-dev) there).
[2005-08-04 16:53:03] [EMAIL PROTECTED]
Now, if we can find a way how PHP can guess the correct timezone from
your windows box (like it can do on most unices) that would be nice -
but I think it's quite impossible.
BTW, if you use error_reporting(E_ALL) you'd have gotten a warning
about this...
[2005-08-04 16:51:34] jeremy at techtrav dot com
I tried adding that line to the top of my code. I am not familar with
that function nor do I find it in the documentation. I get a fatal
error:
Fatal error: Call to undefined function date_default_timezone_set()
when I run this script:
date_default_timezone_set("America/New_York");
echo date('r', (strtotime('oct 25')+(86400*6)));
I would agree with you in your conclusion though that it would appear
that PHP 5.1.X is not reading the timezone of the local machine.
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871&edit=1
#33941 [Asn]: overloading not working with arrays not stored as arrays
ID: 33941
Updated by: [EMAIL PROTECTED]
Reported By: gordon at heydon dot com dot au
Status: Assigned
Bug Type: Class/Object related
Operating System: *
PHP Version: 5CVS-2005-08-02
Assigned To: dmitry
New Comment:
This is not fixable :(
Previous Comments:
[2005-08-05 11:44:23] [EMAIL PROTECTED]
Dmitry "The Fixer", please check this out.
[2005-08-01 12:42:33] stochnagara at hotmail dot com
I've tested this with the lastest win32 binary package. The bug is
still present.
When __get prototype is changed to function & __get everything works
fine.
[2005-08-01 05:48:59] gordon at heydon dot com dot au
Description:
If using the __set() and __get() to store and manipulate arrays within
a property, if the array is not being stored as an array then the array
assignment will not work.
If in the example the property just has the value from the assignment
stored without the serialization, so storing the array within the array
this works.
Also the funny thing is that if you put echos within the __set() and
__get the $obj->prop[5] = 'apple' does not output anything at all. It
is like PHP is trying to guess what the __set() is doing and then doing
that,
Reproduce code:
---
fields[$prop]);
}
public function __set($prop, $value) {
$this->fields[$prop] = serialize($value);
}
private $fields;
}
$obj = new ex;
$obj->prop = array(4 => 'pear');
$obj->prop[5] = 'apple';
var_dump($obj->prop);
?>
Expected result:
array(1) {
[4]=>
string(4) "pear"
[5]=>
string(5) "apple"
}
Actual result:
--
array(1) {
[4]=>
string(4) "pear"
}
--
Edit this bug report at http://bugs.php.net/?id=33941&edit=1
#33301 [NoF->Csd]: PHP crashes in interactive mode
ID: 33301
Updated by: [EMAIL PROTECTED]
Reported By: peter dot buki at vodafone dot hu
-Status: No Feedback
+Status: Closed
Bug Type: Reproducible crash
Operating System: Redhat linux
PHP Version: 5.0.4
New Comment:
Marking as closed then.
Previous Comments:
[2005-08-05 11:54:55] dr dot paul dot thomas at gmail dot com
I've just tried this with php5-STABLE-200508050836 and the bug appears
to have been fixed.
[2005-06-18 01:00:04] 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".
[2005-06-10 16:26:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-06-10 16:19:24] peter dot buki at vodafone dot hu
Description:
If I run php in interactive mode (-a option), and use the code I
supplied below, php crashes with segmentation fault.
It works well without interactive mode.
Reproduce code:
---
$value)
{ print "$key => $value\n" ; }
?>
Expected result:
The following output:
one => 1
two => 2
Actual result:
--
[EMAIL PROTECTED] ~]$ php -a
Interactive mode enabled
$value)
{ print "$key => $value\n" ; }
one => 1
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33301&edit=1
#33301 [Com]: PHP crashes in interactive mode
ID: 33301
Comment by: dr dot paul dot thomas at gmail dot com
Reported By: peter dot buki at vodafone dot hu
Status: No Feedback
Bug Type: Reproducible crash
Operating System: Redhat linux
PHP Version: 5.0.4
New Comment:
I've just tried this with php5-STABLE-200508050836 and the bug appears
to have been fixed.
Previous Comments:
[2005-06-18 01:00:04] 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".
[2005-06-10 16:26:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-06-10 16:19:24] peter dot buki at vodafone dot hu
Description:
If I run php in interactive mode (-a option), and use the code I
supplied below, php crashes with segmentation fault.
It works well without interactive mode.
Reproduce code:
---
$value)
{ print "$key => $value\n" ; }
?>
Expected result:
The following output:
one => 1
two => 2
Actual result:
--
[EMAIL PROTECTED] ~]$ php -a
Interactive mode enabled
$value)
{ print "$key => $value\n" ; }
one => 1
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33301&edit=1
#33941 [Opn->Asn]: overloading not working with arrays not stored as arrays
ID: 33941
Updated by: [EMAIL PROTECTED]
Reported By: gordon at heydon dot com dot au
-Status: Open
+Status: Assigned
Bug Type: Class/Object related
Operating System: *
PHP Version: 5CVS-2005-08-02
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry "The Fixer", please check this out.
Previous Comments:
[2005-08-01 12:42:33] stochnagara at hotmail dot com
I've tested this with the lastest win32 binary package. The bug is
still present.
When __get prototype is changed to function & __get everything works
fine.
[2005-08-01 05:48:59] gordon at heydon dot com dot au
Description:
If using the __set() and __get() to store and manipulate arrays within
a property, if the array is not being stored as an array then the array
assignment will not work.
If in the example the property just has the value from the assignment
stored without the serialization, so storing the array within the array
this works.
Also the funny thing is that if you put echos within the __set() and
__get the $obj->prop[5] = 'apple' does not output anything at all. It
is like PHP is trying to guess what the __set() is doing and then doing
that,
Reproduce code:
---
fields[$prop]);
}
public function __set($prop, $value) {
$this->fields[$prop] = serialize($value);
}
private $fields;
}
$obj = new ex;
$obj->prop = array(4 => 'pear');
$obj->prop[5] = 'apple';
var_dump($obj->prop);
?>
Expected result:
array(1) {
[4]=>
string(4) "pear"
[5]=>
string(5) "apple"
}
Actual result:
--
array(1) {
[4]=>
string(4) "pear"
}
--
Edit this bug report at http://bugs.php.net/?id=33941&edit=1
#33996 [Asn->Csd]: No information given for fatal error on passing invalid value to typed argument
ID: 33996 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at majiclab dot com -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-08-4 Assigned To: dmitry New Comment: Fixed in CVS HEAD. Previous Comments: [2005-08-05 09:52:59] [EMAIL PROTECTED] I think this is not a BUG and it shouldn't be fixed. [2005-08-04 22:50:26] [EMAIL PROTECTED] Nevermind that. I get the same result. (I propably should have eyeglasses or something :) [2005-08-04 22:20:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can NOT reproduce this with latest CVS.. [2005-08-04 19:46:03] [EMAIL PROTECTED] Dmitry, could you plz look at it? I can reproduce it with 5.1 too. [2005-08-04 17:43:45] phpbugs at majiclab dot com Description: When passing an invalid value as a typed argument (as in ! ($argument instanceof typedclass)), a Fatal Error is given, with the following information: Fatal error: Argument 1 must be an object of class Foo in index.php on line 7 The problem is line 7 is the declaration of the function, not the line of code that called the function. It makes bug tracing on a big project next to impossible! Even using ZDE Professional has the same results: I cannot find the function that caused the error (and since the error is fatal, there is no more stack for me to look at). The same goes for missing arguments. Reproduce code: --- Expected result: Warning: Missing argument 1 for NormalTest() in /.../index.php on line 17 Hi! Warning: Argument 1 must be an object of class Foo in /.../ index.php on line 18 Actual result: -- Warning: Missing argument 1 for NormalTest() in /.../index.php on line 12 Hi! Fatal error: Argument 1 must be an object of class Foo in /.../index.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=33996&edit=1
#34001 [Opn->Fbk]: truncating value when optional display width value is used
ID: 34001
Updated by: [EMAIL PROTECTED]
Reported By: james at safesearching dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: *
PHP Version: 5.1.0b3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-08-05 02:36:43] james at safesearching dot com
Description:
PDO seems to be trucating the value from MySQL when using the optional
display width syntax (ie, mediumint(4)).
>From http://dev.mysql.com/doc/mysql/en/numeric-types.html
...
The display width does not constrain the range of values that can be
stored in the column, nor the number of digits that are displayed for
values having a width exceeding that specified for the column.
I'm not sure if that is the goal of PDO here is to acutally constrain
the display width, since I occasionally get junk characters after the
specified length.
ie:
+-+
| id mediumint(4) |
+-+
| 123456 |
+-+
value from PDO is '1234', but sometimes is '1234Àd' or other junk
characters.
Reproduce code:
---
$c = new PDO(
"mysql:dbname=test;host=localhost", '***', '***'
);
// mysql mediumint
// bytes: 3
// minimum: -8388608 / 0
// maximum: 8388607 / 16777215
$c->exec('CREATE TABLE IF NOT EXISTS foo (id mediumint(4), primary key
(id));');
$c->exec("INSERT INTO foo VALUES (12345);");
$c->exec("INSERT INTO foo VALUES (1234567);");
$stmt = $c->prepare("SELECT * FROM foo");
$stmt->execute();
print_r($stmt->fetchAll());
Expected result:
Array
(
[0] => Array
(
[id] => 12345
[0] => 12345
)
[1] => Array
(
[id] => 1234567
[0] => 1234567
)
)
Actual result:
--
Array
(
[0] => Array
(
[id] => 1234
[0] => 1234
)
[1] => Array
(
[id] => 1234
[0] => 1234
)
)
--- or sometimes
Array
(
[0] => Array
(
[id] => 1234À
[0] => 1234À
)
[1] => Array
(
[id] => 1234ÀdL
[0] => 1234ÀdL
)
)
--
Edit this bug report at http://bugs.php.net/?id=34001&edit=1
#34006 [Opn->Fbk]: CLI phpinfo showing html on odbc.default_pw
ID: 34006
Updated by: [EMAIL PROTECTED]
Reported By: csaba at alum dot mit dot edu
-Status: Open
+Status: Feedback
Bug Type:CGI related
PHP Version: 5.1.0b3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Works just fine here.
Previous Comments:
[2005-08-05 11:06:51] csaba at alum dot mit dot edu
Description:
If, on my Win XP Pro, I invoke the CLI php.exe or php-win.exe to do:
then I see that only the odbc.default_pw line has html markup:
odbc.default_pw no value no value
That line seems incorrect, being at odds with the rest of the output
generated, which has no html markup.
Expected result:
OK, the reason for this trivial, though real, report is actually to ask
a question, lest I missed something, before filing a suggestion.
A perfectly reasonable thing to do with CLI PHP is to bring up IE and
have it do things, including displaying html formatted phpinfo(), but
the below code will not format it (as is also noted at
http://bugs.php.net/bug.php?id=28405 )
Navigate("about:blank");
$ie->visible = true;
// try to get formatted phpinfo();
ini_set("html_errors", "1");
ob_start();
phpinfo();
$phpinfo = ob_get_contents();
ob_end_clean();
// output it to IE
$ie->Document->Write($phpinfo);
?>
The suggestion that I got at
http://groups-beta.google.com/group/comp.lang.php/browse_frm/thread/8b98f603dcd62123/
was to use the CGI version of PHP. Which works. But that begs the
question of why have the CLI version at all, then.
Thus, my real question is: Wouldn't it make sense to have phpinfo()
respect the html_errors setting, or, have a 2nd, optional argument on
phpinfo() to allow it use the "other" format. Unless it's already
possible or there's a reason not to, I'll presume to file this as a
suggestion.
Thanks,
Csaba Gabor from Vienna
--
Edit this bug report at http://bugs.php.net/?id=34006&edit=1
#33991 [Fbk->Csd]: Bug test #25665 fails on Solaris
ID: 33991
Updated by: [EMAIL PROTECTED]
Reported By: akim at freedom dot com
-Status: Feedback
+Status: Closed
Bug Type: Math related
Operating System: Solaris 2.9 / SPARC
PHP Version: 5CVS-2005-08-05
New Comment:
Nevermind, you use GCC. :) I'll change the test to be skipped on
solaris, which has this broken behaviour. (all other OSes return NAN
here)
Previous Comments:
[2005-08-05 10:59:47] [EMAIL PROTECTED]
Are you using GCC or some other compiler?
[2005-08-05 01:39:12] akim at freedom dot com
Output:
bash-2.05$ php -r 'var_dump(is_nan(acos(1.01)));'
bool(false)
I also cooked this up to test the hypothesis:
#include
#include
void main()
{
double a;
a = 1.01;
printf("The value of acos(%f) is %f\n", a, acos(a));
}
Output from this is:
The value of acos(1.01) is 0.00
[2005-08-05 01:07:29] [EMAIL PROTECTED]
What does this output for you:
# php -r 'var_dump(is_nan(acos(1.01)));'
[2005-08-04 02:19:08] akim at freedom dot com
Description:
acos() function returns "0" rather than "NAN" for values of |x| > 1.
Among other things this causes test
ext/standard/tests/math/bug25665.phpt to fail.
This may be caused by ambiguous handling of out-of-range arguments in
the Solaris implementation of acos(). From the acos() man page: "If the
value of x is not in the range [-1,1], and is not +-Inf or NaN, either
0.0 or NaN is returned and errno is set to EDOM."
Configure line:
./configure --with-apxs=/www/apache/bin/apxs
--with-mssql=/www/freetds063 --enable-ftp
Dependencies:
libsybdb.so.5 => /www/freetds063/lib/libsybdb.so.5
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 =>/lib/libsocket.so.1
libc.so.1 => /lib/libc.so.1
libresolv.so.2 =>/lib/libresolv.so.2
libm.so.1 => /lib/libm.so.1
libdl.so.1 =>/lib/libdl.so.1
libz.so.1 => /lib/libz.so.1
libxml2.so.2 => /usr/local/lib/libxml2.so.2
libpthread.so.1 => /lib/libpthread.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
libmp.so.2 =>/lib/libmp.so.2
/usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1
libthread.so.1 =>/lib/libthread.so.1
librt.so.1 =>/lib/librt.so.1
libaio.so.1 => /lib/libaio.so.1
libmd5.so.1 => /lib/libmd5.so.1
/usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1
gcc -v output:
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.4.2
Reproduce code:
---
Expected result:
float(NAN)
float(-INF)
Actual result:
--
float(0)
float(-INF)
--
Edit this bug report at http://bugs.php.net/?id=33991&edit=1
#34006 [NEW]: CLI phpinfo showing html on odbc.default_pw
From: csaba at alum dot mit dot edu
Operating system:
PHP version: 5.1.0b3
PHP Bug Type: CGI related
Bug description: CLI phpinfo showing html on odbc.default_pw
Description:
If, on my Win XP Pro, I invoke the CLI php.exe or php-win.exe to do:
then I see that only the odbc.default_pw line has html markup:
odbc.default_pw no value no value
That line seems incorrect, being at odds with the rest of the output
generated, which has no html markup.
Expected result:
OK, the reason for this trivial, though real, report is actually to ask a
question, lest I missed something, before filing a suggestion.
A perfectly reasonable thing to do with CLI PHP is to bring up IE and have
it do things, including displaying html formatted phpinfo(), but the below
code will not format it (as is also noted at
http://bugs.php.net/bug.php?id=28405 )
Navigate("about:blank");
$ie->visible = true;
// try to get formatted phpinfo();
ini_set("html_errors", "1");
ob_start();
phpinfo();
$phpinfo = ob_get_contents();
ob_end_clean();
// output it to IE
$ie->Document->Write($phpinfo);
?>
The suggestion that I got at
http://groups-beta.google.com/group/comp.lang.php/browse_frm/thread/8b98f603dcd62123/
was to use the CGI version of PHP. Which works. But that begs the
question of why have the CLI version at all, then.
Thus, my real question is: Wouldn't it make sense to have phpinfo()
respect the html_errors setting, or, have a 2nd, optional argument on
phpinfo() to allow it use the "other" format. Unless it's already
possible or there's a reason not to, I'll presume to file this as a
suggestion.
Thanks,
Csaba Gabor from Vienna
--
Edit bug report at http://bugs.php.net/?id=34006&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34006&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34006&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34006&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34006&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34006&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34006&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34006&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34006&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34006&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34006&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34006&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34006&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34006&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34006&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34006&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34006&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34006&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34006&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34006&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34006&r=mysqlcfg
#33999 [Asn->Csd]: object remains object when cast to int
ID: 33999
Updated by: [EMAIL PROTECTED]
Reported By: crywolf at kyndimarion dot net
-Status: Assigned
+Status: Closed
Bug Type: Class/Object related
Operating System: *
PHP Version: 5CVS-2005-08-05
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD.
Previous Comments:
[2005-08-05 00:04:43] [EMAIL PROTECTED]
Dmitry, I guess we need to return at least objects index in this
case.
Or maybe use the same way we use when compatibility_mode is on.
What do you think?
[2005-08-04 23:49:03] crywolf at kyndimarion dot net
Description:
When attempting to cast an object to an int, it remains untouched. No
warnings or errors are displayed. The results are the same for (int),
intval(), and settype(). float, bool, string, and array all seem to
work correctly. I get the same results in both 5.0.3 and 5.1.0b3. In
4.3.11, an object can be cast to int.
Reproduce code:
---
Expected result:
object(Foo)#1 (1) {
["bar"]=>
string(3) "bat"
}
int(1)
float(1)
Actual result:
--
object(Foo)#1 (1) {
["bar"]=>
string(3) "bat"
}
object(Foo)#1 (1) {
["bar"]=>
string(3) "bat"
}
Notice: Object of class Foo could not be converted to double in
/home/crywolf/Test/cast_object.php on line 14
float(1)
--
Edit this bug report at http://bugs.php.net/?id=33999&edit=1
#33991 [Opn->Fbk]: Bug test #25665 fails on Solaris
ID: 33991
Updated by: [EMAIL PROTECTED]
Reported By: akim at freedom dot com
-Status: Open
+Status: Feedback
Bug Type: Math related
Operating System: Solaris 2.9 / SPARC
PHP Version: 5CVS-2005-08-05
New Comment:
Are you using GCC or some other compiler?
Previous Comments:
[2005-08-05 01:39:12] akim at freedom dot com
Output:
bash-2.05$ php -r 'var_dump(is_nan(acos(1.01)));'
bool(false)
I also cooked this up to test the hypothesis:
#include
#include
void main()
{
double a;
a = 1.01;
printf("The value of acos(%f) is %f\n", a, acos(a));
}
Output from this is:
The value of acos(1.01) is 0.00
[2005-08-05 01:07:29] [EMAIL PROTECTED]
What does this output for you:
# php -r 'var_dump(is_nan(acos(1.01)));'
[2005-08-04 19:29:30] akim at freedom dot com
Same results with latest snapshot.
[2005-08-04 08:43:08] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-04 02:19:08] akim at freedom dot com
Description:
acos() function returns "0" rather than "NAN" for values of |x| > 1.
Among other things this causes test
ext/standard/tests/math/bug25665.phpt to fail.
This may be caused by ambiguous handling of out-of-range arguments in
the Solaris implementation of acos(). From the acos() man page: "If the
value of x is not in the range [-1,1], and is not +-Inf or NaN, either
0.0 or NaN is returned and errno is set to EDOM."
Configure line:
./configure --with-apxs=/www/apache/bin/apxs
--with-mssql=/www/freetds063 --enable-ftp
Dependencies:
libsybdb.so.5 => /www/freetds063/lib/libsybdb.so.5
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 =>/lib/libsocket.so.1
libc.so.1 => /lib/libc.so.1
libresolv.so.2 =>/lib/libresolv.so.2
libm.so.1 => /lib/libm.so.1
libdl.so.1 =>/lib/libdl.so.1
libz.so.1 => /lib/libz.so.1
libxml2.so.2 => /usr/local/lib/libxml2.so.2
libpthread.so.1 => /lib/libpthread.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
libmp.so.2 =>/lib/libmp.so.2
/usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1
libthread.so.1 =>/lib/libthread.so.1
librt.so.1 =>/lib/librt.so.1
libaio.so.1 => /lib/libaio.so.1
libmd5.so.1 => /lib/libmd5.so.1
/usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1
gcc -v output:
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.4.2
Reproduce code:
---
Expected result:
float(NAN)
float(-INF)
Actual result:
--
float(0)
float(-INF)
--
Edit this bug report at http://bugs.php.net/?id=33991&edit=1
#34005 [Opn->Asn]: ocipasswordchange() fails
ID: 34005 Updated by: [EMAIL PROTECTED] Reported By: uherj at avx dot cz -Status: Open +Status: Assigned Bug Type: OCI8 related Operating System: WinNT PHP Version: 4.4.0 -Assigned To: +Assigned To: tony2001 New Comment: FYI ocipasswordchange() passes correct string to OCI funcs. No idea why it fails. Previous Comments: [2005-08-05 10:51:19] uherj at avx dot cz Description: after sucessful connecting retuns function ocipasswordchange() this output: Warning: ocipasswordchange(): OCIPasswordChange: ORA-28008: invalid old password Password is not changed and ocierror() is empty. With ociinternaldebug(1) do not returns any messaged related to change of passwords. --- Oracle versions are: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production PL/SQL Release 9.2.0.4.0 - Production CORE 9.2.0.3.0 Production TNS for VMS: Version 9.2.0.4.0 - Production NLSRTL Version 9.2.0.4.0 - Production PHP:windows binary distribution, CGI Reproduce code: --- $con=ocilogon($user,$password,$dbstring); $ch=ocipasswordchange($con, $user, $password, $password_new1); Note: same behaviour when passed wrong password: $ch=ocipasswordchange($con, $user, "blahblah", $password_new1); Expected result: change password or return relevant error from Oracle Actual result: -- do not change password, because PHP function ocipasswordchange() passed wrong string to Oracle function OCIPasswordChange -- Edit this bug report at http://bugs.php.net/?id=34005&edit=1
#34005 [NEW]: ocipasswordchange() fails
From: uherj at avx dot cz Operating system: WinNT PHP version: 4.4.0 PHP Bug Type: OCI8 related Bug description: ocipasswordchange() fails Description: after sucessful connecting retuns function ocipasswordchange() this output: Warning: ocipasswordchange(): OCIPasswordChange: ORA-28008: invalid old password Password is not changed and ocierror() is empty. With ociinternaldebug(1) do not returns any messaged related to change of passwords. --- Oracle versions are: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production PL/SQL Release 9.2.0.4.0 - Production CORE 9.2.0.3.0 Production TNS for VMS: Version 9.2.0.4.0 - Production NLSRTL Version 9.2.0.4.0 - Production PHP:windows binary distribution, CGI Reproduce code: --- $con=ocilogon($user,$password,$dbstring); $ch=ocipasswordchange($con, $user, $password, $password_new1); Note: same behaviour when passed wrong password: $ch=ocipasswordchange($con, $user, "blahblah", $password_new1); Expected result: change password or return relevant error from Oracle Actual result: -- do not change password, because PHP function ocipasswordchange() passed wrong string to Oracle function OCIPasswordChange -- Edit bug report at http://bugs.php.net/?id=34005&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34005&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34005&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34005&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34005&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34005&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34005&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34005&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34005&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34005&r=support Expected behavior: http://bugs.php.net/fix.php?id=34005&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34005&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34005&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34005&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34005&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34005&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34005&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34005&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34005&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34005&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34005&r=mysqlcfg
#34004 [Opn->Fbk]: an fatal error on php5ts.dll
ID: 34004
Updated by: [EMAIL PROTECTED]
Reported By: kenji at neojin dot com
-Status: Open
+Status: Feedback
Bug Type: *Web Server problem
Operating System: windows xp
PHP Version: 5.0.4
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Previous Comments:
[2005-08-05 10:44:35] kenji at neojin dot com
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is
alaways the same
Reproduce code:
---
function sansaccent($chaine){
return
strtr($chaine,'àâäåãáÂÄÀÅÃÁæÆçÇéèêëÉÊËÈïîìíÏÎÌÍñÑöôóòõÓÔÖÒÕùûüúÜÛÙÚÿ','aaccnnooy');
}
//creation du fichier xml
$result = $Bdd -> Send_Query("SELECT * FROM file_xml");
if($objet = $Bdd -> get_object($result)){
$id_file = $objet -> id_file_xml;
}
if($id_file<>''){
if(file_exists('../../cache/liste'.$id_file.'.xml')){
@unlink('../../cache/liste'.$id_file.'.xml');
}
$Bdd -> Send_Query("DELETE FROM file_xml");
}
$Bdd -> Send_Query("INSERT INTO file_xml (date,heure)
VALUES
(now(),now())");
$id_xml = $Bdd -> insert_id();
/*$xml = '';*/
$xml .= '';
$i = 1;
$result = $Bdd -> Send_Query("SELECT * FROM maisons");
while($objet = $Bdd -> get_object($result)){
$nom = stripslashes($objet -> m_nom);
$xml .= '
';
}
$xml .= '';
$handle = fopen('../../cache/liste'.$id_xml.'.xml',
'w+');
fwrite($handle, $xml);
fclose($handle);
--
Edit this bug report at http://bugs.php.net/?id=34004&edit=1
#34004 [NEW]: an fatal error on php5ts.dll
From: kenji at neojin dot com
Operating system: windows xp
PHP version: 5.0.4
PHP Bug Type: *Web Server problem
Bug description: an fatal error on php5ts.dll
Description:
A windows erreor in php5ts.dll with windows xp and apache :
php5ts.dll crashes apache 2.0.54
version php5ts.dll : 5.0.4.4
signature :
szAppNAme : Apache.exe
szAppVer : 2.0.54.0
szModName : php5ts.dll
szModVer : 5.0.4.4
offset : 0003b927
I have uninstall php and reinstall it five times but the error is alaways
the same
Reproduce code:
---
function sansaccent($chaine){
return
strtr($chaine,'àâäåãáÂÄÀÅÃÁæÆçÇéèêëÉÊËÈïîìíÏÎÌÍñÑöôóòõÓÔÖÒÕùûüúÜÛÙÚÿ','aaccnnooy');
}
//creation du fichier xml
$result = $Bdd -> Send_Query("SELECT * FROM file_xml");
if($objet = $Bdd -> get_object($result)){
$id_file = $objet -> id_file_xml;
}
if($id_file<>''){
if(file_exists('../../cache/liste'.$id_file.'.xml')){
@unlink('../../cache/liste'.$id_file.'.xml');
}
$Bdd -> Send_Query("DELETE FROM file_xml");
}
$Bdd -> Send_Query("INSERT INTO file_xml (date,heure)
VALUES
(now(),now())");
$id_xml = $Bdd -> insert_id();
/*$xml = '';*/
$xml .= '';
$i = 1;
$result = $Bdd -> Send_Query("SELECT * FROM maisons");
while($objet = $Bdd -> get_object($result)){
$nom = stripslashes($objet -> m_nom);
$xml .= '
';
}
$xml .= '';
$handle = fopen('../../cache/liste'.$id_xml.'.xml',
'w+');
fwrite($handle, $xml);
fclose($handle);
--
Edit bug report at http://bugs.php.net/?id=34004&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34004&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34004&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34004&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34004&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34004&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34004&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34004&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34004&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34004&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34004&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34004&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34004&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34004&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34004&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34004&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34004&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34004&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34004&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34004&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34004&r=mysqlcfg
#34000 [Opn->Bgs]: parameters not passwed correctly
ID: 34000
Updated by: [EMAIL PROTECTED]
Reported By: shim at andersens dot org
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: FC3
PHP Version: 4.3.11
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
Previous Comments:
[2005-08-05 01:09:12] shim at andersens dot org
I havent tried the CVS version because I dont have access to a dev
server to compile the CVS version. Sorry.
[2005-08-05 01:00:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Why didn't you try it before?
[2005-08-05 00:53:17] shim at andersens dot org
Traced it down to a line that read
params[$name];
}
?>
changing it to
...
$v = $this->params[$name];
return $v;
...
fixes it. Is this the same issue fixed in 4.4?
[2005-08-05 00:35:11] [EMAIL PROTECTED]
Your code works perfectly fine here.
Please provide the real one.
[2005-08-05 00:27:08] shim at nadersens dot org
foo('a','b',c')
should be
foo('a','b','c')
also, are varibables are references to eachother. Changing one changes
them all.
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/34000
--
Edit this bug report at http://bugs.php.net/?id=34000&edit=1
#33996 [Asn]: No information given for fatal error on passing invalid value to typed argument
ID: 33996 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at majiclab dot com Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-08-4 Assigned To: dmitry New Comment: I think this is not a BUG and it shouldn't be fixed. Previous Comments: [2005-08-04 22:50:26] [EMAIL PROTECTED] Nevermind that. I get the same result. (I propably should have eyeglasses or something :) [2005-08-04 22:20:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can NOT reproduce this with latest CVS.. [2005-08-04 19:46:03] [EMAIL PROTECTED] Dmitry, could you plz look at it? I can reproduce it with 5.1 too. [2005-08-04 17:43:45] phpbugs at majiclab dot com Description: When passing an invalid value as a typed argument (as in ! ($argument instanceof typedclass)), a Fatal Error is given, with the following information: Fatal error: Argument 1 must be an object of class Foo in index.php on line 7 The problem is line 7 is the declaration of the function, not the line of code that called the function. It makes bug tracing on a big project next to impossible! Even using ZDE Professional has the same results: I cannot find the function that caused the error (and since the error is fatal, there is no more stack for me to look at). The same goes for missing arguments. Reproduce code: --- Expected result: Warning: Missing argument 1 for NormalTest() in /.../index.php on line 17 Hi! Warning: Argument 1 must be an object of class Foo in /.../ index.php on line 18 Actual result: -- Warning: Missing argument 1 for NormalTest() in /.../index.php on line 12 Hi! Fatal error: Argument 1 must be an object of class Foo in /.../index.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=33996&edit=1
#34003 [Opn->Bgs]: bugreports feedback
ID: 34003 Updated by: [EMAIL PROTECTED] Reported By: de at nospam dot net -Status: Open +Status: Bogus Bug Type:*General Issues PHP Version: 5.1.0b3 New Comment: This bug system is not meant for whining. No bug -> bogus. Previous Comments: [2005-08-05 05:20:05] de at nospam dot net Description: I hope the targeted audience is reading this before removing it... I know you are busy doing things... but I think it would be nice to consider the reports a bit more carefully than just writing "this is not a bug"... like it was for example done in #33679 (but I saw it in a few other reports as well). But see #33558 ... if I am not completly wrong, there at least calling a function which returned a reference were eventually accepted to be a bug and fixed. (It does not tell anything about the other two versions though) Which means #33679 was not completly "Bogus". And if you were asking me as a developer (making use of some programming languages), what was in #33679 expected is general practise of OOP. And to me it seemed, that this is something PHP want to move toward. -- Edit this bug report at http://bugs.php.net/?id=34003&edit=1
#34002 [Opn->WFx]: Additional array creation construct
ID: 34002
Updated by: [EMAIL PROTECTED]
Reported By: syncops at hotmail dot com
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5CVS-2005-08-05 (dev)
New Comment:
This was suggested about a year ago too, and we all thought that we
should not add this behavior. You'll have to deal with array().
Previous Comments:
[2005-08-05 03:31:15] syncops at hotmail dot com
Description:
I use associative arrays for so many things like function/method
parameters, database records, creating URL's and HTML tags.
I'm looking at tons of array creation code in my application because
the only way to create an array is by using the array("key1"=>"value1",
"key2"=>"value2") construct.
The following construct would be a very good addition and is also used
in other (script)languages:
{"key1"=>"value1", "key2"=>"value2"}.
I sincerely hope there is some way to implemented this new construct.
Thanks for reading this.
--
Edit this bug report at http://bugs.php.net/?id=34002&edit=1
