#32979 [Com]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 Comment by: lew at mailduct dot com Reported By: mjpph at stardust dot fi Status: Assigned Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: wez -- the problems reported here are all due to a previously fixed bug which has crept back into PHP. It has to do with how the PHP library treats EOF under FreeBSD vs Linux. You worked on this problem previously... please take a look at the currently active Bug #32858 reported by me, as well as your prior fix in Bug #25649. Thanks Lew Payne Previous Comments: [2005-05-30 22:11:28] mjpph at stardust dot fi I haven't had problems with different kernels. Only the combination of x86_64, stream_socket_client() or stream_socket_server(), stream_select() and PHP OpenSSL-support seem to reproduce this every time. [2005-05-30 21:57:34] fox dot 69 at gmx dot net i experience a similar problem since the latest standard kernel update with yum (host.domain.com point to the main server IP) : http://host.domain.com";; $fp = fopen ($url,"r"); $buffer=fread($fp,8192); fclose($fp); echo $buffer; ?> booted with kernel-2.6.11-1.14_FC3 package: OK booted with kernel-2.6.11-1.27_FC3 package: NOT OK (timeout) NOTE: but only if "host.domain.com" point to the executing host itself - same with "localhost" - for all others it seem to be fine [2005-05-30 16:58:42] mjpph at stardust dot fi Also trying to compile valgrind on x86_64 results in: checking for a supported CPU... no (x86_64) configure: error: Unsupported host architecture. Sorry [2005-05-30 16:56:03] mjpph at stardust dot fi I could, but I get this: valgrind: Can only handle 32-bit executables On a 32bit executable and with openssl stream_select() worked ok. On a 64bit PHP executable it doesn't. [2005-05-30 16:33:24] [EMAIL PROTECTED] Can you now check it with valgrind, please? 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#32858 [NoF->Opn]: Bug #25649 has crept back into PHP - Improper feof() handling under FreeBSD
ID: 32858
User updated by: lew at mailduct dot com
Reported By: lew at mailduct dot com
-Status: No Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-REL
PHP Version: 5.0.4, 4.3.10
Assigned To: wez
New Comment:
Bug is still present in latest snapshot of PHP.
Also... there seems to be at least one other bug report that is related
to this problem. See bug #32979. The problem is
directly related (and caused) by faulty stream_select and
stream_get_meta_data behaviour.
In summary:
1) stream_select does not properly detect the presence of additional
input data after it hits an EOF. Neither does stream_get_meta_data.
They both continue to return EOF even for a stream that has new data
(filestream, in my example).
2) stream_select does not properly honor its timeout parameter. If no
data is available, the call should WAIT for the timeout period to expire
before returning due to an EOF condition. Instead, it always returns
immediately with an EOF, making the timeout parameter pointless.
3) stream_select does not properly emulate the select() system call,
which would wait for a timeout if no more data were available (EOF)...
in case more data did become available.
Please let me know how else I can help. I'd like to get this recurring
problem resolved once and for all.
Previous Comments:
[2005-07-05 01:00:05] 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-27 20:52:22] [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-05-27 08:40:27] [EMAIL PROTECTED]
Assigning to Wez since he fixed it last time..
[2005-05-27 00:02:11] lew at mailduct dot com
I have now tested this using PHP 5.0.4 (cli), and the bug remains.
This bug was fixed by [EMAIL PROTECTED] on Sep 2003, but has now crept back
in to both versions 4 and 5 of PHP.
PHP is failing to clear the EOF indicator when reading a stream that
would otherwise BLOCK if read.
--- quote ([EMAIL PROTECTED]):
The PHP streams implementation uses the following logic
for determining the EOF status:
- after a read attempt, if no bytes were read OR
(a read error occurred and the error != EWOULDBLOCK)
--> set the EOF indicator
otherwise, clear the EOF indicator [1]
- after a successful fseek(), clear the EOF indicator.
[1] - this step was missing and has just been comitted to
the CVS.
The feof() function call works like this:
- if stream buffer has data, return false
- otherwise, return the EOF indicator flag.
---endquote
[2005-04-27 21:36:47] lew at mailduct dot com
Description:
In my prior bug report #25649 from September 2003, I pointed out a
serious bug in how PHP handles FEOF under FreeBSD. It was fixed by
[EMAIL PROTECTED] and committed.
This same problem (improper handling of feof() by PHP under FreeBSD)
has now crept into current 4.3.X versions of PHP...
Problem: Once set, the FEOF indicator is not properly cleared when
more data is appended to a file that is opened for read by a PHP
application.
Example: Suppose I want to "tail" a file using PHP. Once I hit the
EOF, I will no longer be able to read data from that file even when
another application appends to it. This is not the correct behaviour
for feof(), as illustrated by the prior fix done by [EMAIL PROTECTED]
Reproduce code:
---
--- program:
$fp = fopen( '/var/log/maillog','r' );
while( TRUE ) {
$r = array( $fp );
$n = stream_select( $r,$w=NULL,$e=NULL,30 );
if( $n ) {
echo fgets( $fp );
}
}
--- feeder:
echo "This is a test..." >> /var/log/maillog
Expected result:
For as long as PROGRAM is running, each time I run
FEEDER I expect to see PROGRAM output "This is a test..."
but it does not, because once EOF is reached, it is not
properly reset upon more data being appended to the file.
See pr #25649 for historical info...
Actual result:
--
PROGRAM will read the contents of /var/log/maillog until it
reaches EOF, and will not output anything else, even if new
data is appeneded to the file.
--
Edit this bug report at http://bugs.php.net/?id=32858&edit=1
#33760 [Com]: cURL needs to implement CRYPTO_callback functions to prevent locking
ID: 33760 Comment by: daniel-curl at haxx dot se Reported By: eja40 at cam dot ac dot uk Status: Open Bug Type: cURL related Operating System: Redhat 9 PHP Version: 5.0.4 New Comment: This is clearly documented in the libcurl tutorial and has been required by libcurl for years. Available online here: http://curl.haxx.se/libcurl/c/libcurl-tutorial.html#Multi-threading Certainly we are open for other/new solutions, but that doesn't fix this problem for you for older libcurl installations. Previous Comments: [2005-07-20 15:18:08] eja40 at cam dot ac dot uk To help flesh out this problem and the solution - the example OpenSSL locking code is given by cURL here: http://curl.haxx.se/lxr/source/docs/examples/opensslthreadlock.c [2005-07-20 15:12:58] eja40 at cam dot ac dot uk Sorry I don't know how to patch it myself. However cURL insist that this must be implemented at the highest thread level - it cannot be implemented in libcurl (I don't understand why). Therefore it must be implemented in the PHP code. [2005-07-19 00:56:53] [EMAIL PROTECTED] This goes to /dev/null unless you come up with: a) real email address b) patch And I think this is actually something for Curl to fix, not PHP. [2005-07-19 00:48:46] eja40 at cam dot ac dot uk Description: I am experiencing problems when using multi-threaded cURL requests. When I have more than about 5 threads connecting using HTTPS, all subsequent threads fail to connect (regardless of the timeout used). I presume this is because PHP hasn't implemented the CRYPTO_callback functions to prevent OpenSSL locking. Sorry I have no idea how to implement this fix myself - but the solution to the problem is elaborated here: http://curl.haxx.se/mail/lib-2004-06/0086.html -- Edit this bug report at http://bugs.php.net/?id=33760&edit=1
#33896 [NEW]: limited replacement parameter on ereg_replace function
From: wfernandom2004 at yahoo dot com dot br
Operating system: Linux, Ubuntu
PHP version: 4.4.0
PHP Bug Type: Regexps related
Bug description: limited replacement parameter on ereg_replace function
Description:
It is impossible put in the replacement parameter, on ereg_replace
function, one literal text of this format: \digit, e.g, \1, because the
substrings replacements have preference.
It, for me, is interesting when preparing string substituitions
previously, with the ereg_replace function.
Reproduce code:
---
echo ereg_replace("a", "0", "bbabb");
Expected result:
bb\0bb
Actual result:
--
bbabb
--
Edit bug report at http://bugs.php.net/?id=33896&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33896&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33896&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33896&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33896&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33896&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33896&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33896&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33896&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33896&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33896&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33896&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33896&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33896&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33896&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33896&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33896&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33896&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33896&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33896&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33896&r=mysqlcfg
#33533 [Fbk->Opn]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 User updated by: scott dot barnett at thuringowa dot qld dot gov dot au Reported By: scott dot barnett at thuringowa dot qld dot gov dot au -Status: Feedback +Status: Open Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: Getting a compile error: mkdir ext/pdo_sqlite/.libs gcc -Iext/pdo_sqlite/sqlite/src -DPDO_SQLITE_BUNDLED=1 -DSQLITE_OMIT_CURSOR -I/usr/src/apache/php5-200507272030/ext -Iext/pdo_sqlite/ -I/usr/src/apache/php5-200507272030/ext/pdo_sqlite/ -DPHP_ATOM_INC -I/usr/src/apache/php5-200507272030/include -I/usr/src/apache/php5-200507272030/main -I/usr/src/apache/php5-200507272030 -I/usr/include/libxml2 -I/usr/include/mysql -I/usr/src/apache/php5-200507272030/TSRM -I/usr/src/apache/php5-200507272030/Zend -g -Wall -c /usr/src/apache/php5-200507272030/ext/pdo_sqlite/pdo_sqlite.c -o ext/pdo_sqlite/.libs/pdo_sqlite.o In file included from /usr/src/apache/php5-200507272030/ext/pdo_sqlite/pdo_sqlite.c:31: /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:24:21: sqlite3.h: No such file or directory In file included from /usr/src/apache/php5-200507272030/ext/pdo_sqlite/pdo_sqlite.c:31: /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:50: error: syntax error before "sqlite3" /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:50: warning: no semicolon at end of struct or union /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:53: error: syntax error before '}' token /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:53: warning: type defaults to `int' in declaration of `pdo_sqlite_db_handle' /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:53: warning: data definition has no type or storage class /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:56: error: syntax error before "pdo_sqlite_db_handle" /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:56: warning: no semicolon at end of struct or union /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:57: warning: type defaults to `int' in declaration of `stmt' /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:57: warning: data definition has no type or storage class /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:58: error: syntax error before ':' token /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:59: error: syntax error before ':' token /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:60: warning: type defaults to `int' in declaration of `pdo_sqlite_stmt' /usr/src/apache/php5-200507272030/ext/pdo_sqlite/php_pdo_sqlite_int.h:60: warning: data definition has no type or storage class /usr/src/apache/php5-200507272030/ext/pdo_sqlite/pdo_sqlite.c: In function `zm_info_pdo_sqlite': /usr/src/apache/php5-200507272030/ext/pdo_sqlite/pdo_sqlite.c:104: warning: implicit declaration of function `sqlite3_libversion' make: *** [ext/pdo_sqlite/pdo_sqlite.lo] Error 1 I also noticed some warnings quite a bit earlier in the compile process that you may or may not be interested in :) gcc -I/opt/informix/incl/esql -Iext/informix/ -I/usr/src/apache/php5-200507272030/ext/informix/ -DPHP_ATOM_INC -I/usr/src/apache/php5-200507272030/include -I/usr/src/apache/php5-200507272030/main -I/usr/src/apache/php5-200507272030 -I/usr/include/libxml2 -I/usr/include/mysql -I/usr/src/apache/php5-200507272030/TSRM -I/usr/src/apache/php5-200507272030/Zend -g -Wall -c /usr/src/apache/php5-200507272030/ext/informix/ifx.c -o ext/informix/.libs/ifx.o /usr/src/apache/php5-200507272030/ext/informix/ifx.ec: In function `php_ifx_do_connect': /usr/src/apache/php5-200507272030/ext/informix/ifx.ec:537: warning: int format, long int arg (arg 4) /usr/src/apache/php5-200507272030/ext/informix/ifx.ec:542: warning: int format, long int arg (arg 4) /usr/src/apache/php5-200507272030/ext/informix/ifx.ec:646: warning: int format, long int arg (arg 4) /usr/src/apache/php5-200507272030/ext/informix/ifx.ec: In function `zif_ifx_do': /usr/src/apache/php5-200507272030/ext/informix/ifx.ec:1567: warning: int format, long int arg (arg 4) /usr/src/apache/php5-200507272030/ext/informix/ifx.ec: In function `zif_ifx_fetch_row': /usr/src/apache/php5-200507272030/ext/informix/ifx.ec:2169: warning: int format, int4 arg (arg 4) /usr/src/apache/php5-200507272030/ext/informix/ifx.ec: In function `zif_ifx_htmltbl_result': /usr/src/apache/php5-200507272030/ext/informix/ifx.ec:2504: warning: int format, int4 arg (arg 4) /usr/src/apache/php5-200507272030/ext/informix/ifx.ec: In function `php_intifx_getType': /usr/src/apache/php5-200507272030/ext/informix/ifx.ec:3052: warning: int format, long int arg (arg 4) /usr/src/apache/php5-200507272030/ext/informix/ifx.ec: In function `php_intifx_copy_blob': /usr/src/apache/ph
#33877 [Bgs->Opn]: When multiple result sets are not freed subsequent queries fail
ID: 33877 User updated by: Jeffrey dot Rodriguez at gmail dot com Reported By: Jeffrey dot Rodriguez at gmail dot com -Status: Bogus +Status: Open Bug Type: MSSQL related Operating System: Windows XP / 2000 PHP Version: 5.0.4 Assigned To: fmk New Comment: PHP documentation does not reflect that this is the case. Since it is PHP or the libraries that PHP uses to interface with MSSQL that are bombing out, the docs should mention this. A meaningful warning should also be thrown. Potentially freeing the result automatically in the background before issuing a new query since it will fail otherwise anyway. Previous Comments: [2005-07-27 19:20:43] [EMAIL PROTECTED] SQL Server does not allow new queries when results are pending. The client must fetch all results or free unwanted results before new queries can be executed. [2005-07-27 17:46:57] Jeffrey dot Rodriguez at gmail dot com Issue still occurs with the latest CVS snapshot. [2005-07-27 13:52:45] [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-07-27 01:16:38] Jeffrey dot Rodriguez at gmail dot com Typo: Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. Should read: Failure to do so will cause subsequent mssql_query() or mssql_select_db() calls to fail. [2005-07-27 00:53:09] Jeffrey dot Rodriguez at gmail dot com Description: NOTE: This issue seems to occur in versions (atleast) 4.3.4 - 5.0.4 WORKAROUND: Be sure to call mssql_free_result() on every result that has the potential to return multiple result sets. PROBLEM: When a query (stored procedure for example) returns multiple result sets, you have to call mssql_next_result() OR mssql_free_result() on the result of an mssql_query(). Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. ADDITIONAL NOTES: The docs should be updated if this functionality is intended. Sorry about the 'excessive' length of code, I figure you can handle 8 extra lines. Reproduce code: --- Expected result: No output Actual result: -- Warning: mssql_select_db(): Unable to select database: database in H:\proofOfConcept.php on line 16 Broken, as expected. -- Edit this bug report at http://bugs.php.net/?id=33877&edit=1
#33895 [NEW]: Constants introduced in 4.0.2 not defined anymore.
From: gpelleti at matrox dot com Operating system: Windows PHP version: 5.1.0b3 PHP Bug Type: Math related Bug description: Constants introduced in 4.0.2 not defined anymore. Description: Math constants M_SQRTPI, M_SQRT3, M_LNPI and M_EULER introduced in version 4.0.2 are not defined anymore in version 5.1.0b3. Reproduce code: --- echo 'M_SQRTPI=' . M_SQRTPI . '' . "\n"; echo 'M_SQRT3=' . M_SQRT3 . '' . "\n"; echo 'M_LNPI=' . M_LNPI . '' . "\n"; echo 'M_EULER=' . M_EULER . '' . "\n"; Expected result: M_SQRTPI=1.7724538509055 M_SQRT3=1.7320508075689 M_LNPI=1.1447298858494 M_EULER=0.57721566490153 Actual result: -- Notice: Use of undefined constant M_SQRTPI - assumed 'M_SQRTPI' in c:\Inetpub\wwwroot\php\math.php on line 23 M_SQRTPI=M_SQRTPI Notice: Use of undefined constant M_SQRT3 - assumed 'M_SQRT3' in c:\Inetpub\wwwroot\php\math.php on line 24 M_SQRT3=M_SQRT3 Notice: Use of undefined constant M_LNPI - assumed 'M_LNPI' in c:\Inetpub\wwwroot\php\math.php on line 25 M_LNPI=M_LNPI Notice: Use of undefined constant M_EULER - assumed 'M_EULER' in c:\Inetpub\wwwroot\php\math.php on line 26 M_EULER=M_EULER -- Edit bug report at http://bugs.php.net/?id=33895&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33895&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33895&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33895&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33895&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33895&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33895&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33895&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33895&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33895&r=support Expected behavior: http://bugs.php.net/fix.php?id=33895&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33895&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33895&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33895&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33895&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33895&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33895&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33895&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33895&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33895&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33895&r=mysqlcfg
#33894 [NEW]: __MAIN_FILE__ constant
From: marcos dot neves at gmail dot com Operating system: any PHP version: 5.1.0b3 PHP Bug Type: Feature/Change Request Bug description: __MAIN_FILE__ constant Description: Today we have __FILE__ constant, that has the string fileName of the current scrit. Would be nice a constant __MAIN_FILE__, wich has the file name of the first requested PHP file. So would be possible to do things like this, without use of external library, and is interesting to everyone: Reproduce code: --- or used to include relative paths to an application, without define constants -- Edit bug report at http://bugs.php.net/?id=33894&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33894&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33894&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33894&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33894&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33894&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33894&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33894&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33894&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33894&r=support Expected behavior: http://bugs.php.net/fix.php?id=33894&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33894&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33894&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33894&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33894&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33894&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33894&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33894&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33894&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33894&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33894&r=mysqlcfg
#33210 [Csd->Opn]: getimagesize() fails to detect width/height on certain JPEGs
ID: 33210
User updated by: polone at townnews dot com
Reported By: polone at townnews dot com
-Status: Closed
+Status: Open
Bug Type: GetImageSize related
Operating System: RedHat Linux 7.3
PHP Version: 4.3.11
New Comment:
This is NOT fixed. Raising the limit to 25 0xFF markers doesn't fix
this issue - it merely fixes certain JPEGs that have less than 25 0xFF
markers, but not all.
Previous Comments:
[2005-06-02 00:29:29] [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-06-01 07:54:18] polone at townnews dot com
Description:
The getimagesize() function fails on specific JPEG files. The reason is
that php_next_marker() in:
ext/standard/image.c
has an artificial limit of 10 imposed on the number of 0xFF records
that are found in sequential order. As far as I can tell ... the JPEG
file format standards impose no such limit (see,
http://www.jpeg.org/public/jfif.pdf). The proper behaviour should be to
continue to read for the next marker until:
(1) M_SOS is found, in which case, image data has begun and no more
headers will occur
(2) M_EOI has occurred (End of Image header) - this is the proper
behavior in a properly encoded image
(3) EOF - something's wrong - but, at least it's not getimagesize()
I've provided an example of a JPEG file that will fail using
getimagesize() online at:
http://www.townnews.com/contrib/premature.jpg
A fix is easily added by removing the artificial limit and just
incrementing "a" in the marker's main loop around line 404:
if (++a > 10)
{
/* who knows the maxim amount of 0xff? though 7 */
/* but found other implementations */
return M_EOI;
}
I realize this may be in place to prevent infinite loops, but the
reality is EOF will do that for us anyway. To fix the problem, just
switch that code hunk too:
a++;
Reproduce code:
---
http://www.townnews.com/contrib/premature.jpg";;
print_r(getimagesize($sURL));
?>
Expected result:
Array
(
[0] => 350
[1] => 603
[2] => 2
[3] => width="350" height="603"
[bits] => 8
[channels] => 3
[mime] => image/jpeg
)
--
Edit this bug report at http://bugs.php.net/?id=33210&edit=1
#33893 [NEW]: $_SERVER['STARTUP_MICRO_TIME']
From: marcos dot neves at gmail dot com Operating system: any PHP version: 5.1.0b3 PHP Bug Type: Feature/Change Request Bug description: $_SERVER['STARTUP_MICRO_TIME'] Description: $_SERVER['REQUEST_TIME'] is a very nice feature, But since many scripts runs in less than 0.1 seconds, would be nice exists a $_SERVER['STARTUP_MICRO_TIME'], so would be possible do something like below: Reproduce code: --- Expected result: A fine grained time elapse calculation Actual result: -- not perfect time elapse calculation -- Edit bug report at http://bugs.php.net/?id=33893&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33893&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33893&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33893&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33893&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33893&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33893&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33893&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33893&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33893&r=support Expected behavior: http://bugs.php.net/fix.php?id=33893&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33893&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33893&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33893&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33893&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33893&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33893&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33893&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33893&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33893&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33893&r=mysqlcfg
#33892 [Opn->Bgs]: serialize contains invalid chars
ID: 33892
Updated by: [EMAIL PROTECTED]
Reported By: marcos dot neves at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: any
PHP Version: 5.1.0b3
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
See bug #29865.
Previous Comments:
[2005-07-27 22:42:13] marcos dot neves at gmail dot com
Description:
serialized string returned by serialize, contains invalid chars only
when serializing an object with protected or private properties.
Reproduce code:
---
Expected result:
comment protected and uncomment public and the right result is given:
[[O:3:"Foo":1:{s:3:"bar";i:123;}]]
Actual result:
--
[[O:3:"Foo":1:{s:6:"
wich means:
[[O:3:"Foo":1:{s:6:"NULL*NULLbar";i:123;}]]
where NULL is the char \0
--
Edit this bug report at http://bugs.php.net/?id=33892&edit=1
#33892 [NEW]: serialize contains invalid chars
From: marcos dot neves at gmail dot com
Operating system: any
PHP version: 5.1.0b3
PHP Bug Type: Unknown/Other Function
Bug description: serialize contains invalid chars
Description:
serialized string returned by serialize, contains invalid chars only when
serializing an object with protected or private properties.
Reproduce code:
---
Expected result:
comment protected and uncomment public and the right result is given:
[[O:3:"Foo":1:{s:3:"bar";i:123;}]]
Actual result:
--
[[O:3:"Foo":1:{s:6:"
wich means:
[[O:3:"Foo":1:{s:6:"NULL*NULLbar";i:123;}]]
where NULL is the char \0
--
Edit bug report at http://bugs.php.net/?id=33892&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33892&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33892&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33892&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33892&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33892&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33892&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33892&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33892&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33892&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33892&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33892&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33892&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33892&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33892&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33892&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33892&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33892&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33892&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33892&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33892&r=mysqlcfg
#33891 [NEW]: make array a traversable
From: marcos dot neves at gmail dot com
Operating system: any
PHP version: 5.1.0b3
PHP Bug Type: Feature/Change Request
Bug description: make array a traversable
Description:
Traversable is an internal interface that says "I can be used in a
foreach". Since array can be used too, would be nice if array be accepted
internally in parameters that expect traversable.
Reproduce code:
---
$v) {
echo "$k=>$v\n";
}
}
function acceptTraversable(Traversable $t) {
echo "\n".__FUNCTION__."\n";
foreach($t as $k=>$v) {
echo "$k=>$v\n";
}
}
$test = array("is", "array", "traversable", "too", "?");
acceptArray($test); // ok
acceptTraversable(new ArrayIterator($test)); // ok
acceptTraversable($test); // would be nice
?>
Expected result:
acceptTraversable($test); shoud accept an array, since it's too a
Traversable structure(can be used in a foreach).
Actual result:
--
Fatal error: Argument 1 must be an object of class Traversable
--
Edit bug report at http://bugs.php.net/?id=33891&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33891&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33891&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33891&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33891&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33891&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33891&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33891&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33891&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33891&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33891&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33891&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33891&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33891&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33891&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33891&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33891&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33891&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33891&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33891&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33891&r=mysqlcfg
#33888 [Bgs]: join does not use objects' __toString() fcn
ID: 33888
Updated by: [EMAIL PROTECTED]
Reported By: wckits at rit dot edu
Status: Bogus
Bug Type: Class/Object related
-Operating System: SunOS
+Operating System: *
-PHP Version: 5.0.3
+PHP Version: 5.1.*
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Atm (5.0, 5.1) __toString() is only being support by echo and print
(see above). We decided to look into this issue after 5.1 is out.
Previous Comments:
[2005-07-27 18:27:30] [EMAIL PROTECTED]
"It is worth noting that the __toString method will only be called when
it is directly combined with echo() or print()."
http://www.php.net/manual/en/language.oop5.magic.php
[2005-07-27 18:24:39] wckits at rit dot edu
Description:
Calling join(",",$array_of_objects) will return
"object,object,object..." even if all of those objects have toString
functions defined.
--
Edit this bug report at http://bugs.php.net/?id=33888&edit=1
#33881 [Opn->Csd]: better "overloading"
ID: 33881 Updated by: [EMAIL PROTECTED] Reported By: robert dot sevcik at gmail dot com -Status: Open +Status: Closed Bug Type: Feature/Change Request -Operating System: all +Operating System: * -PHP Version: 5CVS-2005-07-27 (dev) +PHP Version: * New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php The existing functions cannot be changed in the way requested because that would be a major BC. Introducing new magic functions makes no sense because we have already too much magic. Furthermore adding a non magic way would slow down object execution far too much. As a consequence the only possible ways out would be: 1) Go with interface ArrayAccess and use array notation instead of property notation. 2) Implement an extensions that implements objects that support this kind of thing. 3) Implement a new way of hooking based on interface like ArrayAccess but for properties. Since we already support (1) we won't change anything simply because there is no need (thus Fixed in release). In the end what we really need is real property implementation, where any decalred proeprty can specify whether it is a normal property, a property that can only store a certain king of instance and/or whether it is controlled by handler functions rather than by direct read/write access. Previous Comments: [2005-07-27 13:28:24] robert dot sevcik at gmail dot com Description: Actual state of "overloading", which in PHP5 means "dynamic way to work with object props and methods" is a bit frustrating. I'd like to express my point of view if there is a chance to change... it is a whole philosophy may be for PHP 5.6 or at least PHP6 1) __get() __set() __call() methods should be called whenever they are present in class, not only if another member of suplied name exists. You can always decide within the method whether to use existing member or not. 2) there should be always a default in every class which can be overriden: providing access to existing members + working with setters and getters (getVar() xor get_var() style), true method overloading could be implemented in default as well (multiple method sign. with parameter type checking must be implemented, type spec for trivial types as well). 3) there should be a way to distinguish between public, protected and private ( func_get_access_type() ) and to chek which type members are ( class_get_member_access_type() ) 4) it should work recursively and set/get together which (not working) i consider as a bug of current implementation 5) protos should be __get($name, & $value) __set($name, $value) __call($name, $args, & $returnValue) ; methods should return "Ok, handled", or "No, not handled" ; engine should try from child to parant classes to find which class accepted the call ; if none, raise an error. 6) there should be a way to document dynamic properties and methods - i know this is a litle OT - so it can be used for phpDoc, autocomplete and so on. (abstract properties syntax?) - yes now I see - that could be accomplished just by 1) 7) some introspection is needed what coheres with 7) for soap and similar specialities and for functions like serialize(), isset(), method_exists() .. no idea how to... __get() __set() __call() could return list of handled members when called without args, or there could be a new function __tell() for this? 8) everything should work transparently the same way as static members do - this sums up 1-7 :) ... :) excuse my english pls :) happy PHPing -- Edit this bug report at http://bugs.php.net/?id=33881&edit=1
#33889 [Bgs]: Array_map will not accept print() or echo() functions
ID: 33889 User updated by: wckits at rit dot edu Reported By: wckits at rit dot edu Status: Bogus Bug Type: *General Issues Operating System: SunOS PHP Version: 5.0.3 New Comment: This bug is just another instance of PHP's current near-complete lack of orthogonality. This is a 'serious flaw' more than a bug, but there is no 'fundimental problems with the language that no one will admit to' database. Previous Comments: [2005-07-27 20:04:39] wckits at rit dot edu This bug is just another instance of PHP's current near-complete lack of orthogonality. This is a 'serious flaw' more than a bug, but there is no 'fundemental problems with the language that no one will admit to' database. [2005-07-27 18:28:33] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Because print & echo are language constructs, not functions. [2005-07-27 18:26:54] wckits at rit dot edu Description: The array_map will not accept print() or echo() as callback functions. -- Edit this bug report at http://bugs.php.net/?id=33889&edit=1
#33889 [Bgs]: Array_map will not accept print() or echo() functions
ID: 33889 User updated by: wckits at rit dot edu Reported By: wckits at rit dot edu Status: Bogus Bug Type: *General Issues Operating System: SunOS PHP Version: 5.0.3 New Comment: This bug is just another instance of PHP's current near-complete lack of orthogonality. This is a 'serious flaw' more than a bug, but there is no 'fundemental problems with the language that no one will admit to' database. Previous Comments: [2005-07-27 18:28:33] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Because print & echo are language constructs, not functions. [2005-07-27 18:26:54] wckits at rit dot edu Description: The array_map will not accept print() or echo() as callback functions. -- Edit this bug report at http://bugs.php.net/?id=33889&edit=1
#32241 [Bgs]: Why not have mssql_insert_id function when use Microsoft sql server database!
ID: 32241
Updated by: [EMAIL PROTECTED]
Reported By: kangtk at 163 dot com
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows2000 Server
PHP Version: 4.3.10
New Comment:
It is possible to obtain this value from the server with an explicit
sql statement:
INSERT INTO jobs (job_desc,min_lvl,max_lvl) VALUES
('Accountant',12,125)
SELECT @@IDENTITY AS 'Identity'
Previous Comments:
[2005-07-27 11:12:48] [EMAIL PROTECTED]
The underlying library doesn't provide something like that, so PHP
doesn't provide a wrapper.
There is nothing we can do, ask MS about it.
[2005-07-27 04:05:48] Daniel dot Spada at det dot wa dot edu dot au
To expand on the previous poster. I have found that there is no such
function mssql_insert_id() when using MS-SQL server.
I am using PHP 4.3.10-15, with SQL server 2000. A mssql_insert_id
function would be REALLY handy to assist in error checking etc.
[2005-03-09 03:10:31] kangtk at 163 dot com
Description:
I can use this function mysql_insert_id to get the insert id when I
connect with mysql database.
But I cann't use the mssql_insert_id when I change the code to
Microsoft Sql server databse.
Can you explain something to me?
Thanks.
--
Edit this bug report at http://bugs.php.net/?id=32241&edit=1
#33877 [Opn->Bgs]: When multiple result sets are not freed subsequent queries fail
ID: 33877 Updated by: [EMAIL PROTECTED] Reported By: Jeffrey dot Rodriguez at gmail dot com -Status: Open +Status: Bogus Bug Type: MSSQL related Operating System: Windows XP / 2000 PHP Version: 5.0.4 Assigned To: fmk New Comment: SQL Server does not allow new queries when results are pending. The client must fetch all results or free unwanted results before new queries can be executed. Previous Comments: [2005-07-27 17:46:57] Jeffrey dot Rodriguez at gmail dot com Issue still occurs with the latest CVS snapshot. [2005-07-27 13:52:45] [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-07-27 01:16:38] Jeffrey dot Rodriguez at gmail dot com Typo: Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. Should read: Failure to do so will cause subsequent mssql_query() or mssql_select_db() calls to fail. [2005-07-27 00:53:09] Jeffrey dot Rodriguez at gmail dot com Description: NOTE: This issue seems to occur in versions (atleast) 4.3.4 - 5.0.4 WORKAROUND: Be sure to call mssql_free_result() on every result that has the potential to return multiple result sets. PROBLEM: When a query (stored procedure for example) returns multiple result sets, you have to call mssql_next_result() OR mssql_free_result() on the result of an mssql_query(). Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. ADDITIONAL NOTES: The docs should be updated if this functionality is intended. Sorry about the 'excessive' length of code, I figure you can handle 8 extra lines. Reproduce code: --- Expected result: No output Actual result: -- Warning: mssql_select_db(): Unable to select database: database in H:\proofOfConcept.php on line 16 Broken, as expected. -- Edit this bug report at http://bugs.php.net/?id=33877&edit=1
#33877 [Asn->Opn]: When multiple result sets are not freed subsequent queries fail
ID: 33877 Updated by: [EMAIL PROTECTED] Reported By: Jeffrey dot Rodriguez at gmail dot com -Status: Assigned +Status: Open Bug Type: MSSQL related Operating System: Windows XP / 2000 PHP Version: 5.0.4 Assigned To: fmk Previous Comments: [2005-07-27 17:46:57] Jeffrey dot Rodriguez at gmail dot com Issue still occurs with the latest CVS snapshot. [2005-07-27 13:52:45] [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-07-27 01:16:38] Jeffrey dot Rodriguez at gmail dot com Typo: Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. Should read: Failure to do so will cause subsequent mssql_query() or mssql_select_db() calls to fail. [2005-07-27 00:53:09] Jeffrey dot Rodriguez at gmail dot com Description: NOTE: This issue seems to occur in versions (atleast) 4.3.4 - 5.0.4 WORKAROUND: Be sure to call mssql_free_result() on every result that has the potential to return multiple result sets. PROBLEM: When a query (stored procedure for example) returns multiple result sets, you have to call mssql_next_result() OR mssql_free_result() on the result of an mssql_query(). Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. ADDITIONAL NOTES: The docs should be updated if this functionality is intended. Sorry about the 'excessive' length of code, I figure you can handle 8 extra lines. Reproduce code: --- Expected result: No output Actual result: -- Warning: mssql_select_db(): Unable to select database: database in H:\proofOfConcept.php on line 16 Broken, as expected. -- Edit this bug report at http://bugs.php.net/?id=33877&edit=1
#33877 [Opn->Asn]: When multiple result sets are not freed subsequent queries fail
ID: 33877 Updated by: [EMAIL PROTECTED] Reported By: Jeffrey dot Rodriguez at gmail dot com -Status: Open +Status: Assigned Bug Type: MSSQL related Operating System: Windows XP / 2000 PHP Version: 5.0.4 -Assigned To: +Assigned To: fmk Previous Comments: [2005-07-27 17:46:57] Jeffrey dot Rodriguez at gmail dot com Issue still occurs with the latest CVS snapshot. [2005-07-27 13:52:45] [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-07-27 01:16:38] Jeffrey dot Rodriguez at gmail dot com Typo: Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. Should read: Failure to do so will cause subsequent mssql_query() or mssql_select_db() calls to fail. [2005-07-27 00:53:09] Jeffrey dot Rodriguez at gmail dot com Description: NOTE: This issue seems to occur in versions (atleast) 4.3.4 - 5.0.4 WORKAROUND: Be sure to call mssql_free_result() on every result that has the potential to return multiple result sets. PROBLEM: When a query (stored procedure for example) returns multiple result sets, you have to call mssql_next_result() OR mssql_free_result() on the result of an mssql_query(). Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. ADDITIONAL NOTES: The docs should be updated if this functionality is intended. Sorry about the 'excessive' length of code, I figure you can handle 8 extra lines. Reproduce code: --- Expected result: No output Actual result: -- Warning: mssql_select_db(): Unable to select database: database in H:\proofOfConcept.php on line 16 Broken, as expected. -- Edit this bug report at http://bugs.php.net/?id=33877&edit=1
#33889 [Opn->Bgs]: Array_map will not accept print() or echo() functions
ID: 33889 Updated by: [EMAIL PROTECTED] Reported By: wckits at rit dot edu -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: SunOS PHP Version: 5.0.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Because print & echo are language constructs, not functions. Previous Comments: [2005-07-27 18:26:54] wckits at rit dot edu Description: The array_map will not accept print() or echo() as callback functions. -- Edit this bug report at http://bugs.php.net/?id=33889&edit=1
#33888 [Opn->Bgs]: join does not use objects' __toString() fcn
ID: 33888
Updated by: [EMAIL PROTECTED]
Reported By: wckits at rit dot edu
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: SunOS
PHP Version: 5.0.3
New Comment:
"It is worth noting that the __toString method will only be called when
it is directly combined with echo() or print()."
http://www.php.net/manual/en/language.oop5.magic.php
Previous Comments:
[2005-07-27 18:24:39] wckits at rit dot edu
Description:
Calling join(",",$array_of_objects) will return
"object,object,object..." even if all of those objects have toString
functions defined.
--
Edit this bug report at http://bugs.php.net/?id=33888&edit=1
#33889 [NEW]: Array_map will not accept print() or echo() functions
From: wckits at rit dot edu Operating system: SunOS PHP version: 5.0.3 PHP Bug Type: *General Issues Bug description: Array_map will not accept print() or echo() functions Description: The array_map will not accept print() or echo() as callback functions. -- Edit bug report at http://bugs.php.net/?id=33889&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33889&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33889&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33889&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33889&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33889&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33889&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33889&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33889&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33889&r=support Expected behavior: http://bugs.php.net/fix.php?id=33889&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33889&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33889&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33889&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33889&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33889&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33889&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33889&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33889&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33889&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33889&r=mysqlcfg
#33888 [NEW]: join does not use objects' __toString() fcn
From: wckits at rit dot edu
Operating system: SunOS
PHP version: 5.0.3
PHP Bug Type: Class/Object related
Bug description: join does not use objects' __toString() fcn
Description:
Calling join(",",$array_of_objects) will return "object,object,object..."
even if all of those objects have toString functions defined.
--
Edit bug report at http://bugs.php.net/?id=33888&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33888&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33888&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33888&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33888&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33888&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33888&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33888&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33888&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33888&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33888&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33888&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33888&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33888&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33888&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33888&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33888&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33888&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33888&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33888&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33888&r=mysqlcfg
#33877 [Fbk->Opn]: When multiple result sets are not freed subsequent queries fail
ID: 33877 User updated by: Jeffrey dot Rodriguez at gmail dot com Reported By: Jeffrey dot Rodriguez at gmail dot com -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: Windows XP / 2000 PHP Version: 5.0.4 New Comment: Issue still occurs with the latest CVS snapshot. Previous Comments: [2005-07-27 13:52:45] [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-07-27 01:16:38] Jeffrey dot Rodriguez at gmail dot com Typo: Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. Should read: Failure to do so will cause subsequent mssql_query() or mssql_select_db() calls to fail. [2005-07-27 00:53:09] Jeffrey dot Rodriguez at gmail dot com Description: NOTE: This issue seems to occur in versions (atleast) 4.3.4 - 5.0.4 WORKAROUND: Be sure to call mssql_free_result() on every result that has the potential to return multiple result sets. PROBLEM: When a query (stored procedure for example) returns multiple result sets, you have to call mssql_next_result() OR mssql_free_result() on the result of an mssql_query(). Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. ADDITIONAL NOTES: The docs should be updated if this functionality is intended. Sorry about the 'excessive' length of code, I figure you can handle 8 extra lines. Reproduce code: --- Expected result: No output Actual result: -- Warning: mssql_select_db(): Unable to select database: database in H:\proofOfConcept.php on line 16 Broken, as expected. -- Edit this bug report at http://bugs.php.net/?id=33877&edit=1
#33887 [Opn->Fbk]: array_diff returns empty in some cases
ID: 33887
Updated by: [EMAIL PROTECTED]
Reported By: jestrada at webmedia dot com dot mx
-Status: Open
+Status: Feedback
Bug Type: Arrays related
Operating System: Win
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.
I don't see any calls to array_diff() in your code.
Previous Comments:
[2005-07-27 17:35:59] jestrada at webmedia dot com dot mx
Description:
the default function array_diff returns empty records in some cases. i
have two arrays
1) (1),(3),(7),(9)
2) (2),(3)
it must return r) (1), (7), (9), but it returns (), (), (9)
i made a similar function by my self, and i had the same problem, then
i review the code, and i found a line, a simple counter:
if ($l_existe == false){
$arr_result[$i] = $st_valorComparado;
$i_result++;
}
the var $i must be $i_result, that's why the array contains in
somecases, in which the number of found elements is less than the max
elements, the empty recs, because $arr_result[$i] is putting the value
of $st_valorComparado in another index higher than the max of elements
found.
Maybe the code of the original funcion have a similar error.
Reproduce code:
---
function fcn_array_diff($arr_comparado, $arr_compararEn){
$i_maxComparado = count($arr_comparado);
$i_maxCompararEn = count($arr_compararEn);
$arr_result[0] = "";
$i_result = 0;
for ($i=0; $i<$i_maxComparado; $i++){
$st_valorComparado = chop($arr_comparado[$i]);
$l_existe = false;
for ($j=0; $j<$i_maxCompararEn; $j++){
$st_valorCompararEn = chop($arr_compararEn[$j]);
if ($st_valorComparado == $st_valorCompararEn){
$l_existe = true;
break;
}
}
if ($l_existe == false){
$arr_result[$i_result] = $st_valorComparado;
$i_result++;
}
}
return $arr_result;
}
--
Edit this bug report at http://bugs.php.net/?id=33887&edit=1
#33887 [NEW]: array_diff returns empty in some cases
From: jestrada at webmedia dot com dot mx
Operating system: Win
PHP version: 5.0.4
PHP Bug Type: Arrays related
Bug description: array_diff returns empty in some cases
Description:
the default function array_diff returns empty records in some cases. i
have two arrays
1) (1),(3),(7),(9)
2) (2),(3)
it must return r) (1), (7), (9), but it returns (), (), (9)
i made a similar function by my self, and i had the same problem, then i
review the code, and i found a line, a simple counter:
if ($l_existe == false){
$arr_result[$i] = $st_valorComparado;
$i_result++;
}
the var $i must be $i_result, that's why the array contains in somecases,
in which the number of found elements is less than the max elements, the
empty recs, because $arr_result[$i] is putting the value of
$st_valorComparado in another index higher than the max of elements
found.
Maybe the code of the original funcion have a similar error.
Reproduce code:
---
function fcn_array_diff($arr_comparado, $arr_compararEn){
$i_maxComparado = count($arr_comparado);
$i_maxCompararEn = count($arr_compararEn);
$arr_result[0] = "";
$i_result = 0;
for ($i=0; $i<$i_maxComparado; $i++){
$st_valorComparado = chop($arr_comparado[$i]);
$l_existe = false;
for ($j=0; $j<$i_maxCompararEn; $j++){
$st_valorCompararEn = chop($arr_compararEn[$j]);
if ($st_valorComparado == $st_valorCompararEn){
$l_existe = true;
break;
}
}
if ($l_existe == false){
$arr_result[$i_result] = $st_valorComparado;
$i_result++;
}
}
return $arr_result;
}
--
Edit bug report at http://bugs.php.net/?id=33887&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33887&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33887&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33887&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33887&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33887&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33887&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33887&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33887&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33887&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33887&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33887&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33887&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33887&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33887&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33887&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33887&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33887&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33887&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33887&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33887&r=mysqlcfg
#33876 [Opn]: PDO misquotes/miscasts bool(false)
ID: 33876
User updated by: php at sagi dot org
Reported By: php at sagi dot org
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
New Comment:
For what it's worth, its seems like the pgsql _client_ library that my
installation is compiled against is v7.4.7, even though the server is
running v8.0.
So I guess it never used native prepared statements and the workaround
that you suggested had no affect - they're already disabled.
Previous Comments:
[2005-07-27 16:40:54] php at sagi dot org
Nope, still get the same exception and the same query is being executed
according to the server log.
Still using the same php5-200507261230 snapshot.
The exact code:
$res = $db->prepare(
'SELECT id,name,trial FROM shops WHERE trial = ?',
array(PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT =>
true)
);
$res->execute(array(false));
And the result:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input
syntax for type boolean: ""' in /home/shopy/dev/tmp/test.php:12
Stack trace:
#0 /home/shopy/dev/tmp/test.php(12): PDOStatement->execute(Array)
#1 {main}
thrown in /home/shopy/dev/tmp/test.php on line 12
[2005-07-27 16:25:22] [EMAIL PROTECTED]
Try this as a workaround for now:
$res = $db->prepare('SELECT ...', array(
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT => true
));
You can blame the pretty poor native prepared statement API in pgsql
for this one; it just doesn't tell PDO anything about the parameter
types so it can't make an informed decision about how to treat the
parameters.
[2005-07-27 15:56:26] php at sagi dot org
I know how string casting works, but this is not a string.
PDO knows, for example, how to convert PHP NULL to SQL NULL and not
string('') (like string casting does). Why can't it cast bool values to
an integer instead?
This behavior is bad. PDO knows how to cast the value to real php bool
when selecting, but cannot cast it back when inserting/updating, which
means a simple attempt to re-insert a row that has just been selected,
using the same object, fails.
[2005-07-27 15:16:02] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
[2005-07-27 00:14:50] php at sagi dot org
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to
pgsql 8.0 server.
I'm trying to run a query similar to this:
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text
representation: 7 ERROR: invalid input syntax for type boolean: ""'
The query that has been executed, according to the server log, is:
"SELECT id FROM table WHERE mybool = ''"
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#32139 [Asn->Csd]: base64binary encode/decode
ID: 32139
Updated by: [EMAIL PROTECTED]
Reported By: rtroll at yahoo-inc dot com
-Status: Assigned
+Status: Closed
Bug Type: SOAP related
Operating System: *
PHP Version: 5CVS-2005-02-28
Assigned To: dmitry
New Comment:
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
Previous Comments:
[2005-03-28 17:57:10] forvia at yandex dot ru
SoapClient do not decode response which in base64Binary format...
[2005-02-28 22:04:25] rtroll at yahoo-inc dot com
Changed summary. For some reason, summary kept the same value as my
previously submitted bug.
[2005-02-28 22:02:00] rtroll at yahoo-inc dot com
Description:
When building a SOAP client or server that uses the "base64Binary" XML
datatype, PHP is not performing the appropriate B64 encoding/decoding.
When generating a SOAP client based on a WSDL, the PHP SOAP extension
builds a collection of methods for me. These methods take args (as
defined by the WSDL), and send them over the wire to the appropriate
service. The extension takes care of encoding arrays as arrays,
decimals as decimals, etc. If the item datatype is "base64Binary", the
extension does not b64 encode the value - it merely places it in the
XML.
This may be a feature, requiring client authors to read through the
WSDL to determine what datatypes are being used, in order to adequately
encode things before passing them into the autogenerated methods. If
this is the appropriate functionality, the "time_t -> dateTime" mapping
should also be removed, providing a consistent, "PHP does no data
munging" approach to generated interfaces.
However, I'd much rather see the extension do the B64 encoding for me.
:)
Consider a service that returns an image: getImage(). It could be
implemented such that the image is transmitted in b64 - but the client
author shouldn't need to know that.
Reproduce code:
---
http://ws1.api.re2.yahoo.com/ws/soap-demo/full.wsdl";;
$SRCBUF = "1234567890abcdefghijklmnopqrstuvwxyz";
$client = new SoapClient( $WSDL, array( "trace" => true,
"exceptions" => 0,
));
function dump_xml( $title, $body )
{
$nl = preg_replace( "/\>\\n<", $body );
$clean = htmlspecialchars( $nl );
print "\n$title\n$clean\n";
}
$r = $client->echoViaBase64( array( 'src' => $SRCBUF ));
dump_xml( "Request", $client->__getLastRequest() );
dump_xml( "Response", $client->__getLastResponse() );
?>
Expected result:
The request generated by this PHP5 SOAP client contains the following
body:
1234567890abcdefghijklmnopqrstuvwxyz
Actual result:
--
The request should look something like this:
MTIzNDU2Nzg5MGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6
--
Edit this bug report at http://bugs.php.net/?id=32139&edit=1
#33882 [Opn->Csd]: php.ini search path with CLI api
ID: 33882 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Configuration Issues Operating System: linux PHP Version: 5CVS-2005-07-27 (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-07-27 14:52:59] [EMAIL PROTECTED] Description: the first place to look for a php.ini is supposed to be the directory where the php binary is installed this is done by taking the dirname out of sapi_module.executable_location and then appending php.ini on the other hand sapi_module.executable_location is just a copy of argv[0] for CLI so if the CLI is just called as 'php' it looks for php.ini in "php/php.ini" a realpath() call should be added somewhere to fix this Reproduce code: --- strace php 2>&1 | grep php.ini Expected result: php.ini looked for in /usr/local/bin/php.ini Actual result: -- php.ini looked for in php/php.ini -- Edit this bug report at http://bugs.php.net/?id=33882&edit=1
#33884 [Bgs]: "Only variable references should be returned by reference" if I return nothing
ID: 33884
User updated by: php-bug-33884 at ryandesign dot com
-Reported By: php-bugs-2005 at ryandesign dot com
+Reported By: php-bug-33884 at ryandesign dot com
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: N/A
PHP Version: 4.4.0
New Comment:
Thank you for your response.
I already checked the documentation on functions returning
by reference and could not find any indication that such
functions must always return something. If this is the case,
then this should be documented. If it already is documented,
I would appreciate a direct link to the relevant page.
I have many years of experience in software development,
software testing and bug reporting, and did not think my bug
report had been filed improperly. If you have specific
suggestions for how I could make future bug reports more
useful to you, by all means please share them with me.
Truly, if my function never returned anything, then as you
say I would not need to declare the it as return-by-
reference. However, I do sometimes need to return a
reference. Therefore the function must be declared in this
way. Here is a more concrete example of what my function
does:
class foo {
function &get_or_set($bar, $baz = null) {
if ($baz) {
$GLOBALS['qux'][$bar] =& $baz;
} else {
return $GLOBALS['qux'][$bar];
}
}
}
In this particular case, I can avoid the error by modifying
the code so that the "else" part occurs unconditionally. I
just couldn't see any reason to require that a return-by-
reference function must return a value, when return-by-copy
functions are not restricted in this manner. If such a
reason exists, please enlighten me.
Previous Comments:
[2005-07-27 16:14:27] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
If you don\'t return anything you don\'t need
return-by-reference...
[2005-07-27 15:02:41] php-bug-33884 at ryandesign dot com
Description:
Hi. After upgrading from PHP 4.3.11 to 4.4.0 I get the
famous "Only variable references should be returned by
reference" notice in one of my projects. The function in
question returns by reference, but only needs to do this
sometimes. Other times, it returns nothing at all, because
the caller does not need a return value. In these latter
cases, PHP produces the notice as of 4.4.0.
This surprised me because it's perfectly fine to have a
normal return-by-copy function that does not return
anything. So why not a return-by-reference function?
I couldn't find any documentation that if your function
returns by reference, then you must always return something.
In my particular case I can rewrite the function so that it
always returns something, even when the caller has no use
for it. I just wasn't sure if the notice in this case was
intended, and if so, why.
If the behavior is intended, then the documentation should
reflect this.
Reproduce code:
---
error_reporting(E_ALL);
function &foo_by_reference_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function &foo_by_reference_without_return() {
echo __FUNCTION__ . "\n";
} // line 11
function foo_by_copy_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function foo_by_copy_without_return() {
echo __FUNCTION__ . "\n";
}
foo_by_reference_with_return();
foo_by_reference_without_return(); // causes notice in 4.4.0
foo_by_copy_with_return();
foo_by_copy_without_return();
Expected result:
foo_by_reference_with_return
foo_by_reference_without_return
foo_by_copy_with_return
foo_by_copy_without_return
Actual result:
--
foo_by_reference_with_return
foo_by_reference_without_return
Notice: Only variable references should be returned by
reference in references.php on line 11
foo_by_copy_with_return
foo_by_copy_without_return
--
Edit this bug report at http://bugs.php.net/?id=33884&edit=1
#33489 [Asn->Bgs]: Certain true type fonts shows squares instead of text
ID: 33489 Updated by: [EMAIL PROTECTED] Reported By: informatica at diputacionavila dot es -Status: Assigned +Status: Bogus Bug Type: GD related Operating System: Linux Fedora Core 2 PHP Version: 5.1.0b2 Assigned To: pajoye New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php None of these are somehow valid. Better said they completely broken. The only who do not raise a direct error is weather. I used freetype directly and various freetype debug tools. Fix your fonts, sorry. --Pierre Previous Comments: [2005-07-26 09:18:00] informatica at diputacionavila dot es Here you have links to some problematic fonts http://www.diputacionavila.es/weather.ttf http://www.diputacionavila.es/vacation.ttf http://www.diputacionavila.es/wingdng3.ttf http://www.diputacionavila.es/zaf.ttf If you need anything else... [2005-07-23 18:47:18] [EMAIL PROTECTED] Please provide a link to the ttf fonts causing problems. I may try to allow broken fonts. But only if the changes will not break well defined fonts. --Pierre [2005-06-28 09:08:25] [EMAIL PROTECTED] Pierre, you broke this? :) [2005-06-28 08:26:30] informatica at diputacionavila dot es Freetype libs are the same in both systems. I have also tryed other versions of freetype. I'm talking about php 5.0.3 and beyond, so I've tested it in 5.0.3, 5.0.4 and 5.1.0b2 whith the same result. If I get back to 5.0.2 it works fine. [2005-06-27 14:29:25] [EMAIL PROTECTED] ..and the underlying freetype libs, etc. are the same in both systems? And you're reporting this bug to be in 5.1b2, even as you only talk about 5.0.2 / 3..so REALLY try the b2 before reporting something.. 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/33489 -- Edit this bug report at http://bugs.php.net/?id=33489&edit=1
#33876 [Fbk->Opn]: PDO misquotes/miscasts bool(false)
ID: 33876
User updated by: php at sagi dot org
Reported By: php at sagi dot org
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
New Comment:
Nope, still get the same exception and the same query is being executed
according to the server log.
Still using the same php5-200507261230 snapshot.
The exact code:
$res = $db->prepare(
'SELECT id,name,trial FROM shops WHERE trial = ?',
array(PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT =>
true)
);
$res->execute(array(false));
And the result:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input
syntax for type boolean: ""' in /home/shopy/dev/tmp/test.php:12
Stack trace:
#0 /home/shopy/dev/tmp/test.php(12): PDOStatement->execute(Array)
#1 {main}
thrown in /home/shopy/dev/tmp/test.php on line 12
Previous Comments:
[2005-07-27 16:25:22] [EMAIL PROTECTED]
Try this as a workaround for now:
$res = $db->prepare('SELECT ...', array(
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT => true
));
You can blame the pretty poor native prepared statement API in pgsql
for this one; it just doesn't tell PDO anything about the parameter
types so it can't make an informed decision about how to treat the
parameters.
[2005-07-27 15:56:26] php at sagi dot org
I know how string casting works, but this is not a string.
PDO knows, for example, how to convert PHP NULL to SQL NULL and not
string('') (like string casting does). Why can't it cast bool values to
an integer instead?
This behavior is bad. PDO knows how to cast the value to real php bool
when selecting, but cannot cast it back when inserting/updating, which
means a simple attempt to re-insert a row that has just been selected,
using the same object, fails.
[2005-07-27 15:16:02] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
[2005-07-27 00:14:50] php at sagi dot org
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to
pgsql 8.0 server.
I'm trying to run a query similar to this:
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text
representation: 7 ERROR: invalid input syntax for type boolean: ""'
The query that has been executed, according to the server log, is:
"SELECT id FROM table WHERE mybool = ''"
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#33876 [Opn->Fbk]: PDO misquotes/miscasts bool(false)
ID: 33876
Updated by: [EMAIL PROTECTED]
Reported By: php at sagi dot org
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
New Comment:
Try this as a workaround for now:
$res = $db->prepare('SELECT ...', array(
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT => true
));
You can blame the pretty poor native prepared statement API in pgsql
for this one; it just doesn't tell PDO anything about the parameter
types so it can't make an informed decision about how to treat the
parameters.
Previous Comments:
[2005-07-27 15:56:26] php at sagi dot org
I know how string casting works, but this is not a string.
PDO knows, for example, how to convert PHP NULL to SQL NULL and not
string('') (like string casting does). Why can't it cast bool values to
an integer instead?
This behavior is bad. PDO knows how to cast the value to real php bool
when selecting, but cannot cast it back when inserting/updating, which
means a simple attempt to re-insert a row that has just been selected,
using the same object, fails.
[2005-07-27 15:16:02] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
[2005-07-27 00:14:50] php at sagi dot org
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to
pgsql 8.0 server.
I'm trying to run a query similar to this:
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text
representation: 7 ERROR: invalid input syntax for type boolean: ""'
The query that has been executed, according to the server log, is:
"SELECT id FROM table WHERE mybool = ''"
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#33886 [WFx]: PDO Prepared Statement fails if binding id (:blah) is used more then once.
ID: 33886
User updated by: wb at pro-net dot co dot uk
Reported By: wb at pro-net dot co dot uk
Status: Wont fix
Bug Type: PDO related
Operating System: FreeBSD 5.4-RELEASE-p2
PHP Version: 5.0.4
New Comment:
Fair enougth.
I will submit a note to the php manual about this.
Keep up the good work :)
Previous Comments:
[2005-07-27 16:13:08] [EMAIL PROTECTED]
It's not portable to rely on that.
You need to create three parameters and bind them separately.
[2005-07-27 16:04:28] [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-07-27 16:00:07] wb at pro-net dot co dot uk
Using PDO-0.9 and PDO_PGSQL-0.9
[2005-07-27 15:57:13] wb at pro-net dot co dot uk
Description:
When using the same binding id in a query the PDOStatement::execute()
method still requires you to specify the same amount of parameters.
Reproduce code:
---
setAttribute(PDO_ATTR_ERRMODE, PDO_ERRMODE_EXCEPTION);
$statement = $pdo->prepare("
UPDATE groups
SET
lft = CASE WHEN lft > :right
THEN lft + 2
ELSE lft END,
rgt = CASE WHEN rgt >= :right
THEN rgt + 2
ELSE rgt END
WHERE
rgt >= :right
");
$statement->execute(array(':right' => 5));
?>
Expected result:
Would expect the statement to execute without issue.
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[08P01]: <>: 7 ERROR: bind message supplies 1
parameters, but prepared statement "pdo_pgsql_stmt_08257c0c" requires
3' in /usr/home/wb/bats/scripts/tests/pdoQuery.php:17
Stack trace:
#0 /usr/home/wb/bats/scripts/tests/pdoQuery.php(17):
PDOStatement->execute(Array)
#1 {main}
thrown in /usr/home/wb/bats/scripts/tests/pdoQuery.php on line 17
--
Edit this bug report at http://bugs.php.net/?id=33886&edit=1
#33884 [Opn->Bgs]: "Only variable references should be returned by reference" if I return nothing
ID: 33884
Updated by: [EMAIL PROTECTED]
Reported By: php-bugs-2005 at ryandesign dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: N/A
PHP Version: 4.4.0
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
If you don't return anything you don't need
return-by-reference...
Previous Comments:
[2005-07-27 15:02:41] php-bugs-2005 at ryandesign dot com
Description:
Hi. After upgrading from PHP 4.3.11 to 4.4.0 I get the
famous "Only variable references should be returned by
reference" notice in one of my projects. The function in
question returns by reference, but only needs to do this
sometimes. Other times, it returns nothing at all, because
the caller does not need a return value. In these latter
cases, PHP produces the notice as of 4.4.0.
This surprised me because it's perfectly fine to have a
normal return-by-copy function that does not return
anything. So why not a return-by-reference function?
I couldn't find any documentation that if your function
returns by reference, then you must always return something.
In my particular case I can rewrite the function so that it
always returns something, even when the caller has no use
for it. I just wasn't sure if the notice in this case was
intended, and if so, why.
If the behavior is intended, then the documentation should
reflect this.
Reproduce code:
---
error_reporting(E_ALL);
function &foo_by_reference_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function &foo_by_reference_without_return() {
echo __FUNCTION__ . "\n";
} // line 11
function foo_by_copy_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function foo_by_copy_without_return() {
echo __FUNCTION__ . "\n";
}
foo_by_reference_with_return();
foo_by_reference_without_return(); // causes notice in 4.4.0
foo_by_copy_with_return();
foo_by_copy_without_return();
Expected result:
foo_by_reference_with_return
foo_by_reference_without_return
foo_by_copy_with_return
foo_by_copy_without_return
Actual result:
--
foo_by_reference_with_return
foo_by_reference_without_return
Notice: Only variable references should be returned by
reference in references.php on line 11
foo_by_copy_with_return
foo_by_copy_without_return
--
Edit this bug report at http://bugs.php.net/?id=33884&edit=1
#33886 [Fbk->WFx]: PDO Prepared Statement fails if binding id (:blah) is used more then once.
ID: 33886
Updated by: [EMAIL PROTECTED]
Reported By: wb at pro-net dot co dot uk
-Status: Feedback
+Status: Wont fix
Bug Type: PDO related
Operating System: FreeBSD 5.4-RELEASE-p2
PHP Version: 5.0.4
New Comment:
It's not portable to rely on that.
You need to create three parameters and bind them separately.
Previous Comments:
[2005-07-27 16:04:28] [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-07-27 16:00:07] wb at pro-net dot co dot uk
Using PDO-0.9 and PDO_PGSQL-0.9
[2005-07-27 15:57:13] wb at pro-net dot co dot uk
Description:
When using the same binding id in a query the PDOStatement::execute()
method still requires you to specify the same amount of parameters.
Reproduce code:
---
setAttribute(PDO_ATTR_ERRMODE, PDO_ERRMODE_EXCEPTION);
$statement = $pdo->prepare("
UPDATE groups
SET
lft = CASE WHEN lft > :right
THEN lft + 2
ELSE lft END,
rgt = CASE WHEN rgt >= :right
THEN rgt + 2
ELSE rgt END
WHERE
rgt >= :right
");
$statement->execute(array(':right' => 5));
?>
Expected result:
Would expect the statement to execute without issue.
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[08P01]: <>: 7 ERROR: bind message supplies 1
parameters, but prepared statement "pdo_pgsql_stmt_08257c0c" requires
3' in /usr/home/wb/bats/scripts/tests/pdoQuery.php:17
Stack trace:
#0 /usr/home/wb/bats/scripts/tests/pdoQuery.php(17):
PDOStatement->execute(Array)
#1 {main}
thrown in /usr/home/wb/bats/scripts/tests/pdoQuery.php on line 17
--
Edit this bug report at http://bugs.php.net/?id=33886&edit=1
#33885 [Opn->Bgs]: HTML_Quickform maximum upload filesize should follow php.ini
ID: 33885
Updated by: [EMAIL PROTECTED]
Reported By: weseman at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: OpenBSD
PHP Version: 4.3.11
New Comment:
Please report PEAR issues into the PEAR bug system:
http://pear.php.net/bugs/
Previous Comments:
[2005-07-27 15:38:18] weseman at gmail dot com
Description:
HTML_Quickform uses a default maximum upload filesize of 1megabyte,
which is set through the private property _maxFileSize. IMO, it would
be better to follow the filesize specified by php.ini, as this is the
value that finally decides what size an upload can be.
Reproduce code:
---
Place this in the constructor:
if (preg_match('/^([0-9]+)([a-zA-Z]*)$/',
ini_get('upload_max_filesize'), $matches)) {
// according to:
//
http://www.php.net/manual/en/faq.using.php#faq.using.shorthandbytes
// valid values are G, M or K, or no multiplier at all.
switch (strtoupper($matches['2'])) {
case 'G':
$this->_maxFileSize = $matches['1'] * 1073741824;
break;
case 'M':
$this->_maxFileSize = $matches['1'] * 1048576;
break;
case 'K':
$this->_maxFileSize = $matches['1'] * 1024;
break;
default:
$this->_maxFileSize = $matches['1'];
}
}
--
Edit this bug report at http://bugs.php.net/?id=33885&edit=1
#33886 [Opn->Fbk]: PDO Prepared Statement fails if binding id (:blah) is used more then once.
ID: 33886
Updated by: [EMAIL PROTECTED]
Reported By: wb at pro-net dot co dot uk
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: FreeBSD 5.4-RELEASE-p2
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
Previous Comments:
[2005-07-27 16:00:07] wb at pro-net dot co dot uk
Using PDO-0.9 and PDO_PGSQL-0.9
[2005-07-27 15:57:13] wb at pro-net dot co dot uk
Description:
When using the same binding id in a query the PDOStatement::execute()
method still requires you to specify the same amount of parameters.
Reproduce code:
---
setAttribute(PDO_ATTR_ERRMODE, PDO_ERRMODE_EXCEPTION);
$statement = $pdo->prepare("
UPDATE groups
SET
lft = CASE WHEN lft > :right
THEN lft + 2
ELSE lft END,
rgt = CASE WHEN rgt >= :right
THEN rgt + 2
ELSE rgt END
WHERE
rgt >= :right
");
$statement->execute(array(':right' => 5));
?>
Expected result:
Would expect the statement to execute without issue.
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[08P01]: <>: 7 ERROR: bind message supplies 1
parameters, but prepared statement "pdo_pgsql_stmt_08257c0c" requires
3' in /usr/home/wb/bats/scripts/tests/pdoQuery.php:17
Stack trace:
#0 /usr/home/wb/bats/scripts/tests/pdoQuery.php(17):
PDOStatement->execute(Array)
#1 {main}
thrown in /usr/home/wb/bats/scripts/tests/pdoQuery.php on line 17
--
Edit this bug report at http://bugs.php.net/?id=33886&edit=1
#15841 [Com]: CRLF to separate mail headers is incorrect
ID: 15841
Comment by: mark at thelecks dot com
Reported By: rha at juggernaut dot com dot au
Status: No Feedback
Bug Type: Mail related
Operating System: Linux
PHP Version: 4.1.2
Assigned To: yohgaki
New Comment:
So has there been any resolution to this? Has PHP made any
modifications to their mail function? or provided a better work around?
Previous Comments:
[2005-06-27 21:41:34] guy dot kastenbaum at filnet dot net
I agree with @patpro, mail() should reformate the headers.
This is my quick-and-dirty workaround (from a Q&D specialist) , in
/etc/php.ini :
sendmail_path = "unix2dos|dos2unix|sendmail -t -i"
Guyzmo -- (don't let me programm after midnight)
[2004-09-28 00:41:06] zap at cyborganic dot net
I suddenly had header problems. Perhaps my host changed mail configs or
updated PHP (they never reply to my email, so I don't ask many
question). In any case, all my beautiful HTML emails were being sent
out with broken headers that yturned them into ugly unreadable text and
code.
I am on a Unix server, so I changed all my /r/n newlines to /n. This
fixed the issue immediately. If you find this happens to you, just use
the appropriate newline characters for your host OS.
THANKS for pointing out this bug!
[2004-06-09 09:25:00] patpro at patpro dot net
Hi,
I would really want official PHP Team confirmation for
comments [18 Apr 2:46pm CEST] and [6 Mar 2002 11:04am
CET].
I'm facing the same problem on FreeBSD 5.x, mod_php4
-4.3.6_1,1
If you follow the documentation (using \r\n) mail() will
output badly formated headers. Many SMTPds or Filters
will rewrite headers (sendmail does, Amavisd-new does,
..., but postfix alone doesn't, for example)
I've set up a shell script to pipe mail()'s output into
a file rather than into a SMTP :
$ more /usr/local/sbin/sendmail.cat
#!/bin/sh
cat > /tmp/mailout
then I've set sendmail path to /usr/local/sbin/
sendmail.cat in httpd.conf :
php_admin_value sendmail_path "/usr/local/sbin/
sendmail.cat"
using \r\n as a header separator results in a mix of \n
and \r\n :
$ cat -v /tmp/mailout
To: [EMAIL PROTECTED]
Subject: un dernier test
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Content-Type: text/html; charset=iso-8859-1^M
MIME-Version: 1.0^M
Content-Transfer-Encoding: 8bit^M
this mix is not RFC compliant and breaks rendering in
many mail clients.
It would be nice to change the php documentation
accordingly, and even nicer to provide mail() with the
ability to reformat headers.
[2004-04-18 14:46:32] phpbug at labres dot at
Documentation of mail() states:
"Note: You must use \r\n to separate headers, although some Unix mail
transfer agents may work with just a single newline (\n)."
This is WRONG. On Unix systems, any line ending (also between header
fields) has to be \n. On Windows Systems, it has to be \r\n.
Here is part of the sounce code in mail.c (in case of a Unix system):
sendmail = popen(sendmail_cmd, "w");
fprintf(sendmail, "To: %s\n", to);
fprintf(sendmail, "Subject: %s\n", subject);
if (headers != NULL) {
fprintf(sendmail, "%s\n", headers);
}
fprintf(sendmail, "\n%s\n", message);
ret = pclose(sendmail);
On Windows Systems, the SMTP session is handled within SendText() in
sendmail.c, which sends headers and message as is, so the line endings
have to be \r\n.
Please correct the above cited note and any samples.
There is a further bug in example 4:
| $headers .= "Bcc: [EMAIL PROTECTED]";
remove the ending line break
The header must not end with a line break. As you can see in above code
snipet, the mail implementation adds a \n at the end of the header.
BTW, this is a documentation problem.
[2002-06-26 01:00:07] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/15841
--
Edit this bug report at http://bugs.php.net/?id=15841&edit=1
#33886 [Opn]: PDO Prepared Statement fails if binding id (:blah) is used more then once.
ID: 33886
User updated by: wb at pro-net dot co dot uk
Reported By: wb at pro-net dot co dot uk
Status: Open
Bug Type: PDO related
Operating System: FreeBSD 5.4-RELEASE-p2
PHP Version: 5.0.4
New Comment:
Using PDO-0.9 and PDO_PGSQL-0.9
Previous Comments:
[2005-07-27 15:57:13] wb at pro-net dot co dot uk
Description:
When using the same binding id in a query the PDOStatement::execute()
method still requires you to specify the same amount of parameters.
Reproduce code:
---
setAttribute(PDO_ATTR_ERRMODE, PDO_ERRMODE_EXCEPTION);
$statement = $pdo->prepare("
UPDATE groups
SET
lft = CASE WHEN lft > :right
THEN lft + 2
ELSE lft END,
rgt = CASE WHEN rgt >= :right
THEN rgt + 2
ELSE rgt END
WHERE
rgt >= :right
");
$statement->execute(array(':right' => 5));
?>
Expected result:
Would expect the statement to execute without issue.
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[08P01]: <>: 7 ERROR: bind message supplies 1
parameters, but prepared statement "pdo_pgsql_stmt_08257c0c" requires
3' in /usr/home/wb/bats/scripts/tests/pdoQuery.php:17
Stack trace:
#0 /usr/home/wb/bats/scripts/tests/pdoQuery.php(17):
PDOStatement->execute(Array)
#1 {main}
thrown in /usr/home/wb/bats/scripts/tests/pdoQuery.php on line 17
--
Edit this bug report at http://bugs.php.net/?id=33886&edit=1
#33886 [NEW]: PDO Prepared Statement fails if binding id (:blah) is used more then once.
From: wb at pro-net dot co dot uk
Operating system: FreeBSD 5.4-RELEASE-p2
PHP version: 5.0.4
PHP Bug Type: PDO related
Bug description: PDO Prepared Statement fails if binding id (:blah) is used
more then once.
Description:
When using the same binding id in a query the PDOStatement::execute()
method still requires you to specify the same amount of parameters.
Reproduce code:
---
setAttribute(PDO_ATTR_ERRMODE, PDO_ERRMODE_EXCEPTION);
$statement = $pdo->prepare("
UPDATE groups
SET
lft = CASE WHEN lft > :right
THEN lft + 2
ELSE lft END,
rgt = CASE WHEN rgt >= :right
THEN rgt + 2
ELSE rgt END
WHERE
rgt >= :right
");
$statement->execute(array(':right' => 5));
?>
Expected result:
Would expect the statement to execute without issue.
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[08P01]: <>: 7 ERROR: bind message supplies 1
parameters, but prepared statement "pdo_pgsql_stmt_08257c0c" requires 3'
in /usr/home/wb/bats/scripts/tests/pdoQuery.php:17
Stack trace:
#0 /usr/home/wb/bats/scripts/tests/pdoQuery.php(17):
PDOStatement->execute(Array)
#1 {main}
thrown in /usr/home/wb/bats/scripts/tests/pdoQuery.php on line 17
--
Edit bug report at http://bugs.php.net/?id=33886&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33886&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33886&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33886&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33886&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33886&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33886&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33886&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33886&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33886&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33886&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33886&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33886&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33886&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33886&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33886&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33886&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33886&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33886&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33886&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33886&r=mysqlcfg
#33876 [Bgs->Opn]: PDO misquotes/miscasts bool(false)
ID: 33876
User updated by: php at sagi dot org
Reported By: php at sagi dot org
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
New Comment:
I know how string casting works, but this is not a string.
PDO knows, for example, how to convert PHP NULL to SQL NULL and not
string('') (like string casting does). Why can't it cast bool values to
an integer instead?
This behavior is bad. PDO knows how to cast the value to real php bool
when selecting, but cannot cast it back when inserting/updating, which
means a simple attempt to re-insert a row that has just been selected,
using the same object, fails.
Previous Comments:
[2005-07-27 15:16:02] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
[2005-07-27 00:14:50] php at sagi dot org
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to
pgsql 8.0 server.
I'm trying to run a query similar to this:
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text
representation: 7 ERROR: invalid input syntax for type boolean: ""'
The query that has been executed, according to the server log, is:
"SELECT id FROM table WHERE mybool = ''"
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#33885 [NEW]: HTML_Quickform maximum upload filesize should follow php.ini
From: weseman at gmail dot com
Operating system: OpenBSD
PHP version: 4.3.11
PHP Bug Type: Feature/Change Request
Bug description: HTML_Quickform maximum upload filesize should follow php.ini
Description:
HTML_Quickform uses a default maximum upload filesize of 1megabyte, which
is set through the private property _maxFileSize. IMO, it would be better
to follow the filesize specified by php.ini, as this is the value that
finally decides what size an upload can be.
Reproduce code:
---
Place this in the constructor:
if (preg_match('/^([0-9]+)([a-zA-Z]*)$/',
ini_get('upload_max_filesize'), $matches)) {
// according to:
//
http://www.php.net/manual/en/faq.using.php#faq.using.shorthandbytes
// valid values are G, M or K, or no multiplier at all.
switch (strtoupper($matches['2'])) {
case 'G':
$this->_maxFileSize = $matches['1'] * 1073741824;
break;
case 'M':
$this->_maxFileSize = $matches['1'] * 1048576;
break;
case 'K':
$this->_maxFileSize = $matches['1'] * 1024;
break;
default:
$this->_maxFileSize = $matches['1'];
}
}
--
Edit bug report at http://bugs.php.net/?id=33885&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33885&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33885&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33885&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33885&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33885&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33885&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33885&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33885&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33885&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33885&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33885&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33885&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33885&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33885&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33885&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33885&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33885&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33885&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33885&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33885&r=mysqlcfg
#33876 [Opn->Bgs]: PDO misquotes/miscasts bool(false)
ID: 33876
Updated by: [EMAIL PROTECTED]
Reported By: php at sagi dot org
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
Previous Comments:
[2005-07-27 00:14:50] php at sagi dot org
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to
pgsql 8.0 server.
I'm trying to run a query similar to this:
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text
representation: 7 ERROR: invalid input syntax for type boolean: ""'
The query that has been executed, according to the server log, is:
"SELECT id FROM table WHERE mybool = ''"
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#33884 [NEW]: "Only variable references should be returned by reference" if I return nothing
From: php-bugs-2005 at ryandesign dot com
Operating system: N/A
PHP version: 4.4.0
PHP Bug Type: Unknown/Other Function
Bug description: "Only variable references should be returned by reference" if
I return nothing
Description:
Hi. After upgrading from PHP 4.3.11 to 4.4.0 I get the
famous "Only variable references should be returned by
reference" notice in one of my projects. The function in
question returns by reference, but only needs to do this
sometimes. Other times, it returns nothing at all, because
the caller does not need a return value. In these latter
cases, PHP produces the notice as of 4.4.0.
This surprised me because it's perfectly fine to have a
normal return-by-copy function that does not return
anything. So why not a return-by-reference function?
I couldn't find any documentation that if your function
returns by reference, then you must always return something.
In my particular case I can rewrite the function so that it
always returns something, even when the caller has no use
for it. I just wasn't sure if the notice in this case was
intended, and if so, why.
If the behavior is intended, then the documentation should
reflect this.
Reproduce code:
---
error_reporting(E_ALL);
function &foo_by_reference_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function &foo_by_reference_without_return() {
echo __FUNCTION__ . "\n";
} // line 11
function foo_by_copy_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function foo_by_copy_without_return() {
echo __FUNCTION__ . "\n";
}
foo_by_reference_with_return();
foo_by_reference_without_return(); // causes notice in 4.4.0
foo_by_copy_with_return();
foo_by_copy_without_return();
Expected result:
foo_by_reference_with_return
foo_by_reference_without_return
foo_by_copy_with_return
foo_by_copy_without_return
Actual result:
--
foo_by_reference_with_return
foo_by_reference_without_return
Notice: Only variable references should be returned by
reference in references.php on line 11
foo_by_copy_with_return
foo_by_copy_without_return
--
Edit bug report at http://bugs.php.net/?id=33884&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33884&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33884&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33884&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33884&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33884&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33884&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33884&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33884&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33884&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33884&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33884&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33884&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33884&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33884&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33884&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33884&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33884&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33884&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33884&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33884&r=mysqlcfg
#33692 [Opn->Bgs]: imagettftext produces no output
ID: 33692 Updated by: [EMAIL PROTECTED] Reported By: a dot vent at procommerz dot de -Status: Open +Status: Bogus Bug Type: GD related Operating System: Debian Linux 3.0 "Woody" PHP Version: 4.4.0 -Assigned To: +Assigned To: pajoye New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Please use bug #33489 from now. Provide the font Arial.ttf (btw, all windows arial work here). http://bugs.php.net/bug.php?id=334 --Pierre Previous Comments: [2005-07-24 18:58:38] a dot vent at procommerz dot de Well, I've tried Freetype 2.1.10 now. The result was that imagettftext produce an unknown function error and didn't work at all... The freetype compile went through perfectly as the php compile did, too. Maybe there's another error (e.g., in my freetype configuration before compiling), but these days I haven't got time enough to discover. For the moment, I can live with creating text only on 8 bit images. Best regards, Andreas [2005-07-18 02:39:52] [EMAIL PROTECTED] Why don't you try with Freetype 2? That might actually work.. [2005-07-15 11:59:33] a dot vent at procommerz dot de Additional note: After further dealing with this issue I found that imagettftext works fine on 8 bit images (when using "imagecreate" instead of "imagecreatetruecolor"), but not on true color images. There is a workaround proposal published by "persa" (http://www.webdeveloper.com/forum/showthread.php?threadid=30767) that is to create two images (one of them at 8 bit) and then merging them together after putting the text onto the 8 bit image. It actually seems to be a bug, doesn't it? Best regards, Andreas [2005-07-14 09:50:28] a dot vent at procommerz dot de Description: The ImageTTFText function produces no result, but also no error. I've tried several font files (Microsoft TT core fonts and also from other sources), several paths (the same dir as the PHP script, relative to DocRoot, absolute path a.s.o.). It looks like not calling imagettftext - the function silently does nothing... I have Debian "Woody" with Apache 1.3.29 / PHP 4.4.0. The GD lib is the bundled one (phpinfo says: "2.0.28 compatible"). The Freetype lib version is 1.4pre, as provided from Debian package manager. PHP configure options: './configure' '--with-apxs=/var/www/bin/apxs' '--with-mysql' '--enable-ftp' '--enable-shared' '--with-iconv' '--with-gd' '--with-curl' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-dom=/usr' '--with-zlib' '--enable-cli' '--with-ttf=/usr' Output snippet from phpinfo: GD Support enabled GD Version bundled (2.0.28 compatible) FreeType Support enabled FreeType Linkage with TTF library GIF Read Support enabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Support enabled XBM Support enabled Reproduce code: --- Expected result: Displays an image with white-colored text "Hello World" in Arial font face on grey background. Actual result: -- Displays an grey-colored image without any text (empty grey box). No error messages. -- Edit this bug report at http://bugs.php.net/?id=33692&edit=1
#33882 [NEW]: php.ini search path with CLI api
From: [EMAIL PROTECTED] Operating system: linux PHP version: 5CVS-2005-07-27 (dev) PHP Bug Type: *Configuration Issues Bug description: php.ini search path with CLI api Description: the first place to look for a php.ini is supposed to be the directory where the php binary is installed this is done by taking the dirname out of sapi_module.executable_location and then appending php.ini on the other hand sapi_module.executable_location is just a copy of argv[0] for CLI so if the CLI is just called as 'php' it looks for php.ini in "php/php.ini" a realpath() call should be added somewhere to fix this Reproduce code: --- strace php 2>&1 | grep php.ini Expected result: php.ini looked for in /usr/local/bin/php.ini Actual result: -- php.ini looked for in php/php.ini -- Edit bug report at http://bugs.php.net/?id=33882&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33882&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33882&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33882&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33882&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33882&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33882&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33882&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33882&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33882&r=support Expected behavior: http://bugs.php.net/fix.php?id=33882&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33882&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33882&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33882&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33882&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33882&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33882&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33882&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33882&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33882&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33882&r=mysqlcfg
#33533 [Opn->Fbk]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 Updated by: [EMAIL PROTECTED] Reported By: scott dot barnett at thuringowa dot qld dot gov dot au -Status: Open +Status: Feedback Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez 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 My bad, I broke the sqlite config.m4 last night. The next snapshot dated after this message should be fixed. Previous Comments: [2005-07-27 07:12:00] scott dot barnett at thuringowa dot qld dot gov dot au Apologies for the delayed response. Trying to compile CVS, getting a missing file error. Not sure if this is related or not. checking for PDO includes... checking for PDO includes... /usr/src/apache/php5-200507270430/ext checking for selected PDO ODBC flavour... unixODBC libs /usr/local/lib, headers/usr/local/include checking for odbc.h in /usr/local/include... no checking for odbcsdk.h in /usr/local/include... no checking for iodbc.h in /usr/local/include... no checking for sqlunix.h in /usr/local/include... no checking for sqltypes.h in /usr/local/include... yes checking for sqlucode.h in /usr/local/include... yes checking for sql.h in /usr/local/include... yes checking for isql.h in /usr/local/include... yes checking for sqlext.h in /usr/local/include... yes checking for isqlext.h in /usr/local/include... yes checking for udbcext.h in /usr/local/include... no checking for sqlcli1.h in /usr/local/include... no checking for LibraryManager.h in /usr/local/include... no checking for cli0core.h in /usr/local/include... no checking for cli0ext.h in /usr/local/include... no checking for cli0cli.h in /usr/local/include... no checking for cli0defs.h in /usr/local/include... no checking for cli0env.h in /usr/local/include... no checking for SQLBindCol in -lodbc... yes checking for SQLAllocHandle in -lodbc... yes checking for PostgreSQL support for PDO... no checking for sqlite 3 driver for PDO... yes checking for PDO includes... (cached) /usr/src/apache/php5-200507270430/ext checking size of char *... 4 ./configure: line 84770: /usr/src/apache/php5-200507270430/sqlite/src/sqlite3.h: No such file or directory configure: error: this package is broken [2005-07-19 17:27:19] [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. Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy! [2005-07-19 05:42:25] [EMAIL PROTECTED] I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column). It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix. The very next snapshot should give you a more decent experience until then. [2005-07-19 05:27:40] scott dot barnett at thuringowa dot qld dot gov dot au (gdb) bt #0 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 #1 0x0064fc76 in kill () from /lib/tls/libc.so.6 #2 0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 "/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c", __zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 #4 0x00d5140c in pdo_stmt_describe_columns (stmt=0x8a1616c) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168 #5 0x00d508c3 in zif_PDO_query (ht=2, return_value=0x89b3b84, return_value_ptr=0x0, this_ptr=0x89b39dc, return_value_used=1) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912 #6 0x00f03eaa in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:184 #7 0x00f04713 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:299 #8 0x00f03b8b in execute (op_array=0x89aeaec) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:87 #9 0x00edd699 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200507122030/Zend/zend.c:1087 #10 0x00e9c995 in php_execute_script (primary_file=0xbfe0f4e0) at /usr/src/apache/php5-200507122030/ma
#33877 [Opn->Fbk]: When multiple result sets are not freed subsequent queries fail
ID: 33877 Updated by: [EMAIL PROTECTED] Reported By: Jeffrey dot Rodriguez at gmail dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Windows XP / 2000 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 Previous Comments: [2005-07-27 01:16:38] Jeffrey dot Rodriguez at gmail dot com Typo: Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. Should read: Failure to do so will cause subsequent mssql_query() or mssql_select_db() calls to fail. [2005-07-27 00:53:09] Jeffrey dot Rodriguez at gmail dot com Description: NOTE: This issue seems to occur in versions (atleast) 4.3.4 - 5.0.4 WORKAROUND: Be sure to call mssql_free_result() on every result that has the potential to return multiple result sets. PROBLEM: When a query (stored procedure for example) returns multiple result sets, you have to call mssql_next_result() OR mssql_free_result() on the result of an mssql_query(). Failure to do so will cause subsequent mssql_next_query() or mssql_select_db() calls to fail. ADDITIONAL NOTES: The docs should be updated if this functionality is intended. Sorry about the 'excessive' length of code, I figure you can handle 8 extra lines. Reproduce code: --- Expected result: No output Actual result: -- Warning: mssql_select_db(): Unable to select database: database in H:\proofOfConcept.php on line 16 Broken, as expected. -- Edit this bug report at http://bugs.php.net/?id=33877&edit=1
#33850 [Opn->Asn]: [PATCH]: Support LDAP_X_OPT_CONNECT_TIMEOUT
ID: 33850 Updated by: [EMAIL PROTECTED] -Summary: PATCH: Support LDAP_X_OPT_CONNECT_TIMEOUT Reported By: skissane at gmail dot com -Status: Open +Status: Assigned -Bug Type: LDAP related +Bug Type: Feature/Change Request -Operating System: Irrelevant +Operating System: * -PHP Version: 4.3.11 +PHP Version: 5CVS, 4CVS (2005-07-27) -Assigned To: +Assigned To: sniper Previous Comments: [2005-07-25 08:55:10] skissane at gmail dot com Description: I have written a patch to support LDAP_X_OPT_CONNECT_TIMEOUT (which is defined by the Netscape LDAP C SDK). This required also changing ldap_connect to call ldap_init instead of ldap_open (but only if LDAP_X_OPT_CONNECT_TIMEOUT is defined), which is necessary if LDAP_X_OPT_CONNECT_TIMEOUT is to do anything. In any case, ldap_open is deprecated, so PHP shouldn't be calling it unless necessary. Reproduce code: --- http://www.mq.edu.au/~skissane/ldap-nsldap-timeout.patch Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=33850&edit=1
#32741 [Opn->Asn]: hang on ociexecute() with collections (only with 10g, works with 9i)
ID: 32741 Updated by: [EMAIL PROTECTED] Reported By: fsurleau at skyservices dot net -Status: Open +Status: Assigned Bug Type: OCI8 related Operating System: linux PHP Version: 4.3.11 -Assigned To: +Assigned To: tony2001 Previous Comments: [2005-04-19 15:27:15] fsurleau at skyservices dot net gdb ./httpd GNU gdb Red Hat Linux (5.3.90-0.20030710.41.2.1rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -X Starting program: /usr/local/apache2/bin/httpd -X kgepop: no error frame to pop to for error 21522 OCI-21522: attempted to use an invalid connection in OCI (object mode only) Errors in file : OCI-21522: attempted to use an invalid connection in OCI (object mode only) - Call Stack Trace - Cannot open /proc/2679/exe. calling call entryargument values in hex location type point(? means dubious value) Program received signal SIGSEGV, Segmentation fault. 0x40e65940 in slrac () from /usr/local/oracle10g/lib/libclntsh.so.10.1 (gdb) bt #0 0x40e65940 in slrac () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #1 0x40eb8a13 in kgdsaaddr () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #2 0x40eb848e in kgdsdst () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #3 0x40a4e80c in skgudmp () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #4 0x40e9a69e in kgepop () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #5 0x40e9ae1a in kgesev () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #6 0x40e9ac1f in kgesec0 () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #7 0x40d327c8 in kodogr2lt () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #8 0x40cbd020 in kosindcv () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #9 0x40cbca9a in kosiend () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #10 0x40cbde4d in kpctor () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #11 0x40cd3332 in ttca2p () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #12 0x40ca05b4 in ttcacr () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #13 0x40ca1487 in ttcdrv () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #14 0x40b4312d in nioqwa () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #15 0x409b4d56 in upirtrc () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #16 0x4094ba0d in kpurcsc () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #17 0x409081b8 in kpuexecv8 () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #18 0x4090a084 in kpuexec () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #19 0x4097e85e in OCIStmtExecute () from /usr/local/oracle10g/lib/libclntsh.so.10.1 #20 0x403afb84 in oci_execute (statement=0x820369c, func=0x404aaff6 "OCIExecute", mode=32) at /home/install/php-4.3.11/ext/oci8/oci8.c:1483 #21 0x403b629f in zif_ociexecute (ht=1, return_value=0x8208fbc, this_ptr=0x0, return_value_used=0) at /home/install/php-4.3.11/ext/oci8/oci8.c:4017 #22 0x4048f71f in execute (op_array=0x81e63c4) at /home/install/php-4.3.11/Zend/zend_execute.c:1654 #23 0x4047ce66 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/install/php-4.3.11/Zend/zend.c:926 #24 0x4044ae84 in php_execute_script (primary_file=0xbffeb9c0) at /home/install/php-4.3.11/main/main.c:1745 #25 0x4049538f in php_handler (r=0x81da8d8) at /home/install/php-4.3.11/sapi/apache2handler/sapi_apache2.c:560 #26 0x08087646 in ap_run_handler (r=0x81da8d8) at config.c:152 #27 0x08087b61 in ap_invoke_handler (r=0x81da8d8) at config.c:364 #28 0x08071365 in ap_process_request (r=0x81da8d8) at http_request.c:249 #29 0x0806d358 in ap_process_http_connection (c=0x81d44b0) at http_core.c:251 #30 0x080907e2 in ap_run_process_connection (c=0x81d44b0) at connection.c:43 #31 0x080862ad in child_main (child_num_arg=0) at prefork.c:610 #32 0x08086360 in make_child (s=0x80c73a0, slot=0) at prefork.c:650 #33 0x0808644a in startup_children (number_to_start=5) at prefork.c:722 #34 0x08086750 in ap_mpm_run (_pconf=0x80c2a50, plog=0x80fab30, s=0x80c73a0) at prefork.c:941 #35 0x0808bc9f in main (argc=2, argv=0xbffebd64) at main.c:618 [2005-04-19 14:35:11] [EMAIL PROTECTED] Are there any entries in the error_log ? If so, use gdb to generate a backtrace. [2005-04-19 14:29:42] fsurleau at skyservices dot net No result means I have nothing because as I
#28972 [Ver->Fbk]: [] operator overflow treatment is incorrect
ID: 28972
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
-Status: Verified
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS, 4CVS (2005-06-19)
New Comment:
Can you respond to the feedback request by Andi?
Previous Comments:
[2005-06-24 00:10:04] [EMAIL PROTECTED]
In the case of an integer overflow, it shouldn't be strange to you that
there might be unpredictable behavior. Is this really a real-life
problem that you are bumping into? If so, can you explain further? I am
not sure if/how this should be addressed especially as different
architectures might behave differently and I don't want to
over-architect something which you shouldn't be bumping into in the
first place...
[2005-04-16 13:05:13] [EMAIL PROTECTED]
/usr/src/php/php5/Zend/zend_execute.c(891) : Freeing 0x09C7786C (16
bytes), script=t.php
[2005-03-06 20:33:58] [EMAIL PROTECTED]
Leaks too:
/usr/src/php/php_4_3/Zend/zend_execute.c(501) : Freeing 0x09ACF6A4 (12
bytes), script=t.php
[2004-06-30 11:08:01] tomas_matousek at hotmail dot com
Description:
If there is an item in an array having key = 2^31-1 and you use []
operator without specifying a key it overflows and adds a new item with
min. int (-2^31) in the array.
This is IMHO not correct or at least not consistent with the manual
where the following sentence is stated:
"If you do not specify a key for a given value, then the maximum of the
integer indices is taken, and the new key will be that maximum value +
1."
Moreover, consider the folowing array:
$a = array(2^31-2 => 1,-2^31 => 1) and use $a[] twice.
You get warning:
"Cannot add element to the array as the next element is already
occupied".
But if the array is $a = array(2^31-1 => 1,-2^31 => 1) a new item is
added with a key -2^31+1 with no warning.
However, if you use array_push instead [] it does never report a
warning but does the same as [].
IMHO it will be more correct if both [] and array_push do not add a new
key and report a warning or notice if the maximal integer key reaches
maximum value 2^31-1.
Reproduce code:
---
$a = array(2147483647 => 1, -2147483648 => 1);
$a[] = 2;
$a[] = 3;
var_dump($a);
$a = array(2147483646 => 1, -2147483648 => 1);
$a[] = 2;
$a[] = 3;
var_dump($a);
Expected result:
Warning: Cannot add element to array - integer key reached maximal
possible value ...
Warning: Cannot add element to array - integer key reached maximal
possible value ...
array(4) {
[2147483647]=>
int(1)
[-2147483648]=>
int(1)
}
Warning: Cannot add element to array - integer key reached maximal
possible value ...
array(3) {
[2147483646]=>
int(1)
[-2147483648]=>
int(1)
[2147483647]=>
int(2)
}
Actual result:
--
array(4) {
[2147483647]=>
int(1)
[-2147483648]=>
int(1)
[-2147483647]=>
int(2)
[-2147483646]=>
int(3)
}
Warning: Cannot add element to the array as the next element is
already occupied in ...
array(3) {
[2147483646]=>
int(1)
[-2147483648]=>
int(1)
[2147483647]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=28972&edit=1
#33881 [NEW]: better "overloading"
From: robert dot sevcik at gmail dot com Operating system: all PHP version: 5CVS-2005-07-27 (dev) PHP Bug Type: Feature/Change Request Bug description: better "overloading" Description: Actual state of "overloading", which in PHP5 means "dynamic way to work with object props and methods" is a bit frustrating. I'd like to express my point of view if there is a chance to change... it is a whole philosophy may be for PHP 5.6 or at least PHP6 1) __get() __set() __call() methods should be called whenever they are present in class, not only if another member of suplied name exists. You can always decide within the method whether to use existing member or not. 2) there should be always a default in every class which can be overriden: providing access to existing members + working with setters and getters (getVar() xor get_var() style), true method overloading could be implemented in default as well (multiple method sign. with parameter type checking must be implemented, type spec for trivial types as well). 3) there should be a way to distinguish between public, protected and private ( func_get_access_type() ) and to chek which type members are ( class_get_member_access_type() ) 4) it should work recursively and set/get together which (not working) i consider as a bug of current implementation 5) protos should be __get($name, & $value) __set($name, $value) __call($name, $args, & $returnValue) ; methods should return "Ok, handled", or "No, not handled" ; engine should try from child to parant classes to find which class accepted the call ; if none, raise an error. 6) there should be a way to document dynamic properties and methods - i know this is a litle OT - so it can be used for phpDoc, autocomplete and so on. (abstract properties syntax?) - yes now I see - that could be accomplished just by 1) 7) some introspection is needed what coheres with 7) for soap and similar specialities and for functions like serialize(), isset(), method_exists() .. no idea how to... __get() __set() __call() could return list of handled members when called without args, or there could be a new function __tell() for this? 8) everything should work transparently the same way as static members do - this sums up 1-7 :) ... :) excuse my english pls :) happy PHPing -- Edit bug report at http://bugs.php.net/?id=33881&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33881&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33881&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33881&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33881&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33881&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33881&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33881&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33881&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33881&r=support Expected behavior: http://bugs.php.net/fix.php?id=33881&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33881&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33881&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33881&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33881&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33881&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33881&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33881&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33881&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33881&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33881&r=mysqlcfg
#33880 [Opn->Bgs]: Bug in function "schemaValidate"
ID: 33880
Updated by: [EMAIL PROTECTED]
Reported By: thomas dot wetzler at siemens dot com
-Status: Open
+Status: Bogus
Bug Type: DOM XML related
Operating System: SUN OS
PHP Version: 5.0.4
New Comment:
the actual XML Schema parsing is done by libxml2 and not PHP. So any
XML Schema "bug" is a libxml2 issue.
I recommend first updating to the latest libxml2 release (2.6.20) as
the XML Schema support made big improvements lately and if the bug
persits, ask on the libxml2 mailinglist (or file a bug report there)
nothing we can do about.
Previous Comments:
[2005-07-27 08:47:55] thomas dot wetzler at siemens dot com
Description:
To validate a dataset, I try to generate a XML-Schema with the help of
an database-definition. The Schema-file is correctly build. XMLSpy
works with it fine... but if I try to run the same files with php, php
reports a failure.
Reproduce code:
---
test.php:
#!/wir/webadmin/share/php504/bin/php
load('gd.xml');
if ($xml->schemaValidate("gd.xsd")) {
echo "Validated OK";
} else {
echo "Validate FAILED";
}
?>
gd.xml:
http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="D:\gp.xsd">
PN
10149764
DT
DEB4 PATENTSCHRIFT
PA
Huettlin, Herbert, Dr.h.c., 79539 Loerrach,
DE.
IN
Huettlin, Herbert, Dr.h.c., 79539 Loerrach,
DE.
gd.xsd:
http://www.w3.org/2001/XMLSchema";
elementFormDefault="qualified">
Expected result:
Validated OK
Actual result:
--
Warning: Element decl. 'subelement': The content model is not
determinist. in /wir/searchservertest/src/load_db/xml_parser/test.php
on line 6
Warning: Invalid Schema in
/wir/searchservertest/src/load_db/xml_parser/test.php on line 6
Validate FAILED
--
Edit this bug report at http://bugs.php.net/?id=33880&edit=1
#32241 [Opn->Bgs]: Why not have mssql_insert_id function when use Microsoft sql server database!
ID: 32241 Updated by: [EMAIL PROTECTED] Reported By: kangtk at 163 dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Windows2000 Server PHP Version: 4.3.10 New Comment: The underlying library doesn't provide something like that, so PHP doesn't provide a wrapper. There is nothing we can do, ask MS about it. Previous Comments: [2005-07-27 04:05:48] Daniel dot Spada at det dot wa dot edu dot au To expand on the previous poster. I have found that there is no such function mssql_insert_id() when using MS-SQL server. I am using PHP 4.3.10-15, with SQL server 2000. A mssql_insert_id function would be REALLY handy to assist in error checking etc. [2005-03-09 03:10:31] kangtk at 163 dot com Description: I can use this function mysql_insert_id to get the insert id when I connect with mysql database. But I cann't use the mssql_insert_id when I change the code to Microsoft Sql server databse. Can you explain something to me? Thanks. -- Edit this bug report at http://bugs.php.net/?id=32241&edit=1
#20298 [Com]: odbc.check_persistent not working
ID: 20298
Comment by: t-yonetani+php at ergobrains dot co dot jp
Reported By: phpbug at tab1 dot clara dot co dot uk
Status: Verified
Bug Type: ODBC related
Operating System: *
PHP Version: 5CVS, 4CVS (2004-04-13)
New Comment:
Here's a patch written according to phpbugs at kevin dot offwhite dot
net's
suggestion(I hope space and tabs won't be damanged). We're using a
similar
version(just by replacing SQLGetInfo() with SQLGetConnectAttr()) on a
spare
machine, and odbc_pconnect() seems to be working so far. Uncommenting
out
the code for fixing #15758 is a bit scary, but I believe it should be
OK.
Index: php_odbc.c
===
RCS file: /repository/php-src/ext/odbc/php_odbc.c,v
retrieving revision 1.143.2.12
diff -u -r1.143.2.12 php_odbc.c
--- php_odbc.c 14 Jun 2003 03:37:30 - 1.143.2.12
+++ php_odbc.c 27 Jul 2005 08:47:05 -
@@ -2156,6 +2156,29 @@
}
/* }}} */
+/* {{{ is_connection_dead */
+static int is_connection_dead(odbc_connection *db_conn)
+{
+#if defined(HAVE_IBMDB2)
+#else
+ UCHAR d_name[32];
+ SWORD len;
+#endif
+ SQLINTEGER dead;
+ RETCODE ret;
+
+#if defined(HAVE_IBMDB2)
+ ret = SQLGetConnectAttr(db_conn->hdbc, SQL_ATTR_CONNECTION_DEAD,
&dead,
+ 0, NULL);
+#else
+ ret = SQLGetInfo(db_conn->hdbc, SQL_DATA_SOURCE_READ_ONLY, d_name,
+sizeof(d_name), &len);
+ dead = len == 0;
+#endif
+ return ret != SQL_SUCCESS || dead;
+}
+/* }}} */
+
/* Persistent connections: two list-types le_pconn, le_conn and a
plist
* where hashed connection info is stored together with index pointer
to
* the actual link of type le_pconn in the list. Only persistent
@@ -2282,23 +2305,13 @@
* check to see if the connection is still in place
(lurcher)
*/
if(ODBCG(check_persistent)){
- RETCODE ret;
- UCHAR d_name[32];
- SWORD len;
-
- ret = SQLGetInfo(db_conn->hdbc,
- SQL_DATA_SOURCE_READ_ONLY,
- d_name, sizeof(d_name), &len);
-
- if(ret != SQL_SUCCESS || len == 0) {
+ if(is_connection_dead(db_conn)) {
zend_hash_del(&EG(persistent_list),
hashed_details, hashed_len +
1);
- /* Commented out to fix a possible
double closure error
-* when working with persistent
connections as submitted by
-* bug #15758
-*
-* safe_odbc_disconnect(db_conn->hdbc);
-* SQLFreeConnect(db_conn->hdbc);
+ /*
+* now that we know the connection is
dead, just free
+* the DBC handle without issuing
SQLDisconnect().
*/
+ SQLFreeConnect(db_conn->hdbc);
goto try_and_get_another_connection;
}
}
Previous Comments:
[2005-04-25 17:19:56] mwilmes at avc dot edu
I am running Apache 2.0.45 and PHP 4.3.11 on Win 2K3 Server. I was
hoping this was only a problem with earlier versions of PHP. My only
indcation is that this happens in the mornings when I come in, and I
would have to restart Apache to clear things up. Our Oracle server
(connected to using ODBC) reboots for its backup, so my server has a
dead ODBC handle when we get in. Until it is fixed or we develop a
workaround, I guess I'll be switching to odbc_connect.
[2004-06-04 22:06:49] phpbugs at kevin dot offwhite dot net
Well, after some additional research I have turned up what I think is
the exact cause of the bug, but I don't feel qualified to implement the
solution.
In the php code, at line 2271 in php_odbc.c (
http://lxr.php.net/source/php-src/ext/odbc/php_odbc.c#2271 ), php calls
SQLGetInfo() passing a parameter of SQL_DATA_SOURCE_READ_ONLY to try and
determine if the connection is alive or not. While this may work in
some odbc drivers, it is not the "official" way of asking if the
connection is dead. According to my driver supplier (
http://www-912.ibm.com/o_dir/odbcforum.nsf/8178b1c14b1e9b6b8525624f0062fe9f/B0CFDBA3D8DBAC0F86256EA80077D2B9?OpenDocument
) and the Microsoft's ODBC Progra
