[PHP-BUG] Bug #53686 [NEW]: mktime(0,0,0, 12,32, 2010) means 2011 1 1 , is it reasonable?
From: Operating system: centos5 PHP version: 5.2.17 Package: Unknown/Other Function Bug Type: Bug Bug description:mktime(0,0,0, 12,32, 2010) means 2011 1 1 , is it reasonable? Description: --- >From manual page: http://www.php.net/function.mktime#Notes --- mktime(0,0,0, 12,32, 2010) means 2011 1 1 , is this reasonable? why not check the date first? Test script: --- print mktime(0,0,0, 12,32, 2010) - mktime(0,0,0, 12,31, 2010); //86400 Expected result: return false . -- Edit bug report at http://bugs.php.net/bug.php?id=53686&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53686&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53686&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53686&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53686&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53686&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53686&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53686&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53686&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53686&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53686&r=support Expected behavior: http://bugs.php.net/fix.php?id=53686&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53686&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53686&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53686&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53686&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53686&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53686&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53686&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53686&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53686&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53686&r=mysqlcfg
Bug #49344 [Com]: pdo_mssql fails to connect,throws PDOException SQLSTATE[] (null) (severity 0)
Edit report at http://bugs.php.net/bug.php?id=49344&edit=1
ID: 49344
Comment by: wrobel at wsb-nlu dot edu dot pl
Reported by:rockyjl at gmai dot com
Summary:pdo_mssql fails to connect,throws PDOException
SQLSTATE[] (null) (severity 0)
Status: No Feedback
Type: Bug
Package:PDO related
Operating System: win2003 X64
PHP Version:5.2.11RC1
Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
It seems that the problem is solved by changing tds version to 7.0
instead of 8.0 in freetds configuration...
Previous Comments:
[2011-01-06 12:11:45] wrobel at wsb-nlu dot edu dot pl
I have the same problem when connecting: PDOException with message
SQLSTATE[] (null) (severity 0).
My environment is:
PHP 5.2.14
apache-2.2.16
Sql Server 2008 Express (and Sql Server 2008 R2)
Linux/PLD
[2009-10-09 18:56:19] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=289440
Log: - Possible fix for bug #49344 on Windows (pdo_mssql fails to
connect,throws PDOException SQLSTATE[] (null) (severity 0))
[2009-10-07 09:14:41] philipp at servicemail24 dot de
The same error occurs using Ubuntu 0910 with Zend Framework:
require_once('Zend/Db.php');
$db = Zend_Db::factory('Pdo_Mssql', array(
'host' => 'sqlsrv',
'username' => 'php',
'password' => 'secret',
'dbname' => 'myDatabase',
'pdoType' => 'dblib'
));
$result = $db->fetchAll(SELECT * FROM MyTable");
var_dump($result);
Zend_Db_Adapter_Exception: SQLSTATE[] (null) (severity 0) in
/usr/share/php/libzend-framework-php/Zend/Db/Adapter/Pdo/Abstract.php on
line 144
[2009-09-23 04:20:01] Rockyjl at gmail dot com
My Modification:
static int pdo_dblib_handle_factory(pdo_dbh_t *dbh, zval *driver_options
TSRMLS_DC)
{
pdo_dblib_db_handle *H;
int i, ret = 0;
char *location = " L=";
struct pdo_data_src_parser vars[] = {
{ "charset",NULL, 0 },
{ "appname","PHP " PDO_DBLIB_FLAVOUR, 0 },
{ "host", "127.0.0.1", 0 },
{ "dbname", NULL, 0 },
{ "secure", NULL, 0 }, /* DBSETLSECURE */
/* TODO: DBSETLVERSION ? */
};
php_pdo_parse_data_source(dbh->data_source, dbh->data_source_len, vars,
5);
H = pecalloc(1, sizeof(*H), dbh->is_persistent);
H->login = dblogin();
H->err.sqlstate = dbh->error_code;
if (!H->login) {
strcat(location, "login");
goto cleanup;
}
if (dbh->username) {
DBSETLUSER(H->login, dbh->username);
}
if (dbh->password) {
DBSETLPWD(H->login, dbh->password);
}
#if !PHP_DBLIB_IS_MSSQL
if (vars[0].optval) {
DBSETLCHARSET(H->login, vars[0].optval);
}
#endif
DBSETLAPP(H->login, vars[1].optval);
#if PHP_DBLIB_IS_MSSQL
dbprocerrhandle(H->login, (EHANDLEFUNC) error_handler);
dbprocmsghandle(H->login, (MHANDLEFUNC) msg_handler);
#endif
H->link = dbopen(H->login, vars[2].optval);
if (H->link == NULL) {
strcat(location, "link");
goto cleanup;
}
/* dblib do not return more than this length from text/image */
DBSETOPT(H->link, DBTEXTLIMIT, "2147483647");
/* limit text/image from network */
DBSETOPT(H->link, DBTEXTSIZE, "2147483647");
if (vars[3].optval && FAIL == dbuse(H->link, vars[3].optval)) {
strcat(location, "optval");
goto cleanup;
}
ret = 1;
dbh->max_escaped_char_length = 2;
dbh->alloc_own_columns = 1;
cleanup:
for (i = 0; i < sizeof(vars)/sizeof(vars[0]); i++) {
if (vars[i].freeme) {
efree(vars[i].optval);
}
}
dbh->methods = &dblib_methods;
dbh->driver_data = H;
if (!ret) {
zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
"SQLSTATE[%s] %s (severity %d) %s", //I want to
findout the bug
location !
DBLIB_G(err).sqlstate,
DBLIB_G(err).dberrstr,
DBLIB_G(err).severity,
location);
}
return ret;
Bug #53686 [Opn->Bgs]: mktime(0,0,0, 12,32, 2010) means 2011 1 1 , is it reasonable?
Edit report at http://bugs.php.net/bug.php?id=53686&edit=1 ID: 53686 Updated by: ahar...@php.net Reported by:huarong at masalife dot com Summary:mktime(0,0,0, 12,32, 2010) means 2011 1 1 , is it reasonable? -Status: Open +Status: Bogus Type: Bug -Package:Unknown/Other Function +Package:Date/time related Operating System: centos5 PHP Version:5.2.17 Block user comment: N Private report: N New Comment: That's how mktime() works. If you want to check the validity of a date, use checkdate(). Previous Comments: [2011-01-07 09:30:59] huarong at masalife dot com Description: --- >From manual page: http://www.php.net/function.mktime#Notes --- mktime(0,0,0, 12,32, 2010) means 2011 1 1 , is this reasonable? why not check the date first? Test script: --- print mktime(0,0,0, 12,32, 2010) - mktime(0,0,0, 12,31, 2010); //86400 Expected result: return false . -- Edit this bug report at http://bugs.php.net/bug.php?id=53686&edit=1
Bug #50829 [Com]: php.ini directive pdo_mysql.default_socket is ignored
Edit report at http://bugs.php.net/bug.php?id=50829&edit=1 ID: 50829 Comment by: hansfn at gmail dot com Reported by:giovanni at giacobbi dot net Summary:php.ini directive pdo_mysql.default_socket is ignored Status: Closed Type: Bug Package:PDO related Operating System: Linux PHP Version:5.3.2RC1 Block user comment: N Private report: N New Comment: I think this is actually fixed. The problem is subtle. Quote from http://www.php.net/manual/en/ref.pdo-mysql.connection.php: -- When the host name is set to "localhost", then the connection to the server is made thru a domain socket. If PDO_MYSQL is compiled against libmysql then the location of the socket file is at libmysql's compiled in location. If PDO_MYSQL is compiled against mysqlnd a default socket can be set thru the pdo_mysql.default_socket setting. -- In other words, pdo_mysql.default_socket is ignored when PDO_MYSQL is compiled against libmysql. I tested (on PHP 5.3.4, CentOS) with the code to reproduce the problem, and got the correct/expect result. But I still got the "Can't connect to local MySQL server through socket" error, because it turned out that PDO_MYSQL was compiled against libmysql - "php -i" tells me "--with-pdo-mysql=shared,/usr/lib/mysql/mysql_config". My problem was that /etc/my.cnf wasn't in sync with /usr/lib/mysql/mysql_config ... Previous Comments: [2010-10-13 17:19:56] mbiechl at jahnsandfriends dot de Confirming that bug still exists in PHP 5.3.3 cli [2010-09-22 14:41:36] gnoodl+php at gmail dot com So we're at v5.3.3 and this bug is still around :( Status should be "Open" [2010-07-23 20:21:24] joelataylor at gmail dot com I'm having this exact issue on 5.3.2 - installed via Zend Server. Having been hitting my head against a brick wall. I obviously can create a symbolic link, or use unix_socket - to point to the correct location - but would prefer localhost to work as expected. [2010-04-23 01:57:46] gnoodl at gmail dot com In which stable version does this fix appear. I've just upgraded to PHP 5.3.2 and whilst pdo_mysql.default_socket is returned correctly via ini_get(), attempting to make a connection results in the following exception SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/tmp/mysql.sock' FYI, my socket file resides at /var/lib/mysql/mysql.sock [2010-03-24 17:49:55] paul at boxuk dot com this, or a problem relating to this fix appears to be seg-faulting the pdo_mysql module on startup in ZTS mode bug #51216 is related commenting out REGISTER_INI_ENTRIES() in ext/pdo_mysql/pdo_mysql.c:68 php startup prevents the seg-fault configure line -- ./configure --enable-maintainer-zts --with-mysql --with-mysqli=mysqlnd --enable- pdo --with-pdo-mysql gdb output -- gdb sapi/cli/php GNU gdb Fedora (6.8-37.el5) This GDB was configured as "i386-redhat-linux-gnu"... (gdb) run Starting program: /php-5.3.2/sapi/cli/php [Thread debugging using libthread_db enabled] [New Thread 0xb7f776c0 (LWP 491)] [New Thread 0xb7d0db90 (LWP 494)] [Thread 0xb7d0db90 (LWP 494) exited] Program received signal SIGSEGV, Segmentation fault. 0x08347ff5 in zend_startup_module_ex (module=0x98d2720, tsrm_ls=0x98b7050) at /opt/BoxUK/install/php-5.3.2/Zend/zend_API.c:1618 1618EG(current_module) = NULL; module->name at this point is "pdo_mysql" 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/bug.php?id=50829 -- Edit this bug report at http://bugs.php.net/bug.php?id=50829&edit=1
Bug #52861 [Com]: unset failes with ArrayObject and deep arrays
Edit report at http://bugs.php.net/bug.php?id=52861&edit=1
ID: 52861
Comment by: auke at muze dot nl
Reported by:mep_eisen at web dot de
Summary:unset failes with ArrayObject and deep arrays
Status: Open
Type: Bug
Package:SPL related
Operating System: Windows Vista 64
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
I found a workaround for the problem that suddenly the parent object has
any
property you try to access and has it filled with the previously set
array.
If the containing object has its own __get() method which always returns
NULL,
the object is safe again. So this code works as expected:
class IWouldLikeToPointOutABug {
function __get( $name ) {
return NULL;
}
}
$buggy = new IWouldLikeToPointOutABug();
$buggy->bug = new ArrayObject( );
$buggy->bug['foo']['bar'] = true;
echo "This looks normal\r\n";
var_dump( $buggy );
echo "This should be NULL\r\n";
var_dump( $buggy->thisIsNotHere );
One drawback is that you cannot assign properties by reference anymore
because
you're now using the __get() overloading method.
This does not fix the original bug where unsetting fails.
BTW. Our original workaround involved creating our own arrayobject by
implementing all the array interfaces, but that will not work either.
When you
do this:
$arrayobject['unsetkey']['key'] = $value;
The offsetSet method is never called for 'unsetKey', just the offsetGet.
So
there is no way to implement the correct behaviour.
Previous Comments:
[2011-01-05 18:51:51] auke at muze dot nl
It's worse than this, ArrayObject gets confused on where to put the data
and mangles any containing object:
test script:
class IWouldLikeToPointOutABug {
}
$buggy = new IWouldLikeToPointOutABug();
$buggy->bug = new ArrayObject( );
$buggy->bug['foo']['bar'] = true;
echo "This looks normal\r\n";
var_dump( $buggy );
echo "This should be NULL\r\n";
var_dump( $buggy->thisIsNotHere );
Results in:
This looks normal
object(IWouldLikeToPointOutABug)#1 (1) {
["bug"]=>
object(ArrayObject)#2 (0) {
}
}
This should be NULL
array(1) {
["bar"]=>
bool(true)
}
[2010-09-16 17:23:11] mep_eisen at web dot de
Description:
Using deep arrays unset itself or ArrayObject misbehaves. It silently
does nothing.
The problem lies in iteration 3 that mixes ArrayObject and classic
arrays.
Test script:
---
echo "iteration1\n";
$arr = new ArrayObject();
$arr['foo'] = new ArrayObject();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
echo "iteration2\n";
$arr = array();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
echo "iteration3\n";
$arr = new ArrayObject();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
Expected result:
iteration1
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
object(ArrayObject)#2 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
}
}
iteration2
array(1) {
["foo"]=>
array(0) {
}
}
iteration3
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
array(0) {
}
}
}
Actual result:
--
iteration1
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
object(ArrayObject)#2 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
}
}
iteration2
array(1) {
["foo"]=>
array(0) {
}
}
iteration3
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
array(1) {
["bar"]=>
bool(true)
}
}
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52861&edit=1
Bug #52861 [Com]: unset failes with ArrayObject and deep arrays
Edit report at http://bugs.php.net/bug.php?id=52861&edit=1
ID: 52861
Comment by: auke at muze dot nl
Reported by:mep_eisen at web dot de
Summary:unset failes with ArrayObject and deep arrays
Status: Open
Type: Bug
Package:SPL related
Operating System: Windows Vista 64
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Just checked with php 5.3.3 and there the code runs as expected, so at
least
setting works with a nested array.
For the record I tried the original bugreport code as well and got the
same
result, on a linux system, 64 bits (debian), but also this notice:
PHP Notice: Indirect modification of overloaded element of ArrayObject
has no
effect in /var/www/test/test.php on line 22
So at least PHP is honest in that it doesn't work :)
Previous Comments:
[2011-01-07 12:07:34] auke at muze dot nl
I found a workaround for the problem that suddenly the parent object has
any
property you try to access and has it filled with the previously set
array.
If the containing object has its own __get() method which always returns
NULL,
the object is safe again. So this code works as expected:
class IWouldLikeToPointOutABug {
function __get( $name ) {
return NULL;
}
}
$buggy = new IWouldLikeToPointOutABug();
$buggy->bug = new ArrayObject( );
$buggy->bug['foo']['bar'] = true;
echo "This looks normal\r\n";
var_dump( $buggy );
echo "This should be NULL\r\n";
var_dump( $buggy->thisIsNotHere );
One drawback is that you cannot assign properties by reference anymore
because
you're now using the __get() overloading method.
This does not fix the original bug where unsetting fails.
BTW. Our original workaround involved creating our own arrayobject by
implementing all the array interfaces, but that will not work either.
When you
do this:
$arrayobject['unsetkey']['key'] = $value;
The offsetSet method is never called for 'unsetKey', just the offsetGet.
So
there is no way to implement the correct behaviour.
[2011-01-05 18:51:51] auke at muze dot nl
It's worse than this, ArrayObject gets confused on where to put the data
and mangles any containing object:
test script:
class IWouldLikeToPointOutABug {
}
$buggy = new IWouldLikeToPointOutABug();
$buggy->bug = new ArrayObject( );
$buggy->bug['foo']['bar'] = true;
echo "This looks normal\r\n";
var_dump( $buggy );
echo "This should be NULL\r\n";
var_dump( $buggy->thisIsNotHere );
Results in:
This looks normal
object(IWouldLikeToPointOutABug)#1 (1) {
["bug"]=>
object(ArrayObject)#2 (0) {
}
}
This should be NULL
array(1) {
["bar"]=>
bool(true)
}
[2010-09-16 17:23:11] mep_eisen at web dot de
Description:
Using deep arrays unset itself or ArrayObject misbehaves. It silently
does nothing.
The problem lies in iteration 3 that mixes ArrayObject and classic
arrays.
Test script:
---
echo "iteration1\n";
$arr = new ArrayObject();
$arr['foo'] = new ArrayObject();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
echo "iteration2\n";
$arr = array();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
echo "iteration3\n";
$arr = new ArrayObject();
$arr['foo']['bar'] = true;
unset($arr['foo']['bar']);
var_dump($arr);
Expected result:
iteration1
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
object(ArrayObject)#2 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
}
}
iteration2
array(1) {
["foo"]=>
array(0) {
}
}
iteration3
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
array(0) {
}
}
}
Actual result:
--
iteration1
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
object(ArrayObject)#2 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
}
}
iteration2
array(1) {
["foo"]=>
array(0) {
}
}
iteration3
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["foo"]=>
array(1) {
["bar"]=>
bool(true)
}
}
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52861&edit=1
Bug #53677 [Csd->Bgs]: xml_parse_into_struct deletes unescaped character data
Edit report at http://bugs.php.net/bug.php?id=53677&edit=1 ID: 53677 Updated by: rricha...@php.net Reported by:lwc at mailmetrash dot com Summary:xml_parse_into_struct deletes unescaped character data -Status: Closed +Status: Bogus Type: Bug Package:XML related Operating System: Redhat Linux PHP Version:5.2.14 Block user comment: N Private report: N 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. dupe of bug #45996 Previous Comments: [2011-01-07 01:25:26] lwc at mailmetrash dot com Sorry, you can delete this bug. The fixed description made me realize it's a duplicate of #45996. [2011-01-06 22:05:23] lwc at mailmetrash dot com Sorry, here's a fixed description.tag should turn into: [name] => this [value] => tag But in some cases it turns into: [name] => this [value] => tag/ That is, it's not even kept. It's just deleted! [2011-01-06 21:48:10] lwc at mailmetrash dot com As for the "(as claimed in)" comment, you can delete it. They actually claim you should use straight up HTML without escaping it. Problem is the parser then treats the HTML tags like XML ones. If you have a solution for that one, please post it there. [2011-01-06 21:40:58] lwc at mailmetrash dot com Description: Assuming #26528 is also valid for the actual character data (as claimed in http://forum.alicebot.org/viewtopic.php?t=69), then the parser should decode into: [name] => this [value] => The problem is in some cases it stays as: [name] => this [value] => In my 2 unrelated servers, the decoding works in v5.2.6 but fails in v5.2.14. Please check in newer versions, if you can! -- Edit this bug report at http://bugs.php.net/bug.php?id=53677&edit=1
Bug #53041 [Com]: is_file() and open_basedir
Edit report at http://bugs.php.net/bug.php?id=53041&edit=1
ID: 53041
Comment by: sjon at react dot com
Reported by:sunseb at live dot com
Summary:is_file() and open_basedir
Status: Verified
Type: Bug
Package:*Directory/Filesystem functions
Operating System: Linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
this problem still occurs in 5.3.5
Previous Comments:
[2010-10-13 02:58:59] uramihsayibok at gmail dot com
Same as bugs #52065 and #44901. Reproduced on Windows.
some file function (eg, is_file) calls the C functions:
-> php_stat
-> php_check_specific_open_basedir(_ex) [1]
-> expand_filepath(_ex)
-> virtual_file_ex
-> tsrm_realpath_r [2]:
Unable to access /home/my_file.txt/whatever, [2] next checks that
/home/my_file.txt exists *and is a directory*. Since it isn't a
directory, everything fails all the way back up to [1], which then,
assuming it was a problem specifically with the open_basedir
restriction, issues the warning.
[2010-10-11 10:38:23] sunseb at live dot com
Description:
php.ini :
open_basedir = /home/
directory :
/home/my_file.txt
script :
is_file('/home/my_file.txt'); // TRUE.
is_file('/home/my_file.txt/whatever'); // FALSE but "Warning:
is_file():
open_basedir restriction in effect." Why this warning (open_basedir is
OK) ?
Thank you ! (And sorry for my english.)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53041&edit=1
Bug #53649 [Asn->Dup]: mysql_query with "load data" unable to save result set
Edit report at http://bugs.php.net/bug.php?id=53649&edit=1
ID: 53649
Updated by: and...@php.net
Reported by:jeremy dot archuleta at gmail dot com
Summary:mysql_query with "load data" unable to save result
set
-Status: Assigned
+Status: Duplicate
Type: Bug
Package:MySQL related
Operating System: Mac OS
PHP Version:5.3.4
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Duplicate of 53503, because of a bug in mysqlnd. No need for a change in
ext/mysql
Previous Comments:
[2011-01-05 20:49:52] jeremy dot archuleta at gmail dot com
Bug is also reported in MySQLi package:
http://bugs.php.net/bug.php?id=53503
And reported to be fixed in PHP 5.3.5
[2011-01-04 16:24:03] jeremy dot archuleta at gmail dot com
Description:
I believe that using mysql_query() with "load data" should always be a
TRUE/FALSE return value. However, if a mysql_query() call that returns a
result
set is performed *before* the "load data" query, then there is a warning
stating
that the result set can not be saved.
In short:
Warning:
mysql_query("SELECT ..."); // result set *before*
mysql_query("LOAD DATA ..."); // warning
Works:
mysql_query("LOAD DATA ..."); // works
mysql_query("SELECT ..."); // result set *after*
Works:
mysql_query("UPDATE ..."); // *no* result set
mysql_query("LOAD DATA ..."); // works
Works and Warning:
mysql_query("LOAD DATA ..."); // works
mysql_query("SELECT ..."); // result set *after*
mysql_query("LOAD DATA ..."); // warning
MacOS 10.5.8
$ uname -a
Darwin clark-kent-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01
PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
Using PHP from macports
$ php --version
PHP 5.3.3 (cli) (built: Oct 25 2010 17:21:53)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
$ php -i
phpinfo()
PHP Version => 5.3.3
System => Darwin clark-kent-2.local 9.8.0 Darwin Kernel Version 9.8.0:
Wed Jul
15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
Build Date => Oct 25 2010 17:19:57
Configure Command => './configure' '--prefix=/opt/local' '--
mandir=/opt/local/share/man' '--infodir=/opt/local/share/info'
'--with-config-
file-path=/opt/local/etc/php5' '--with-config-file-scan-
dir=/opt/local/var/db/php5' '--disable-all' '--enable-bcmath'
'--enable-ctype'
'--enable-dom' '--enable-fileinfo' '--enable-filter' '--enable-hash'
'--enable-
json' '--enable-libxml' '--enable-pdo' '--enable-phar'
'--enable-session' '--
enable-simplexml' '--enable-tokenizer' '--enable-xml'
'--enable-xmlreader' '--
enable-xmlwriter' '--with-bz2=/opt/local' '--with-mhash=/opt/local'
'--with-
pcre-regex=/opt/local' '--with-readline=/opt/local' '--with-libxml-
dir=/opt/local' '--with-zlib=/opt/local' '--disable-cgi' '--with-
apxs2=/opt/local/apache2/bin/apxs' '--with-pear=/opt/local/lib/php'
Using MySQL from macports
$ mysql --version
mysql Ver 14.14 Distrib 5.1.51, for apple-darwin9.8.0 (i386) using
readline 6.1
Test script:
---
Expected result:
This works
This also works
This fails with warning
Actual result:
--
This works
This also works
This fails with warning
Warning: mysql_query(): Unable to save result set in tmp.php on line 18
--
Edit this bug report at http://bugs.php.net/bug.php?id=53649&edit=1
Bug #53483 [Asn->Bgs]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483&edit=1
ID: 53483
Updated by: and...@php.net
Reported by:squarious at gmail dot com
Summary:using mysqli_stmt::send_long_data() makes execute()
fail
-Status: Assigned
+Status: Bogus
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.3.3
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Seems it was a MySQL Server bug which was fixed in 5.5.8 GA and 5.1.5x
Previous Comments:
[2011-01-06 14:28:07] u...@php.net
Andrey,
smells like a server bug fixed in the latest 5.0, 5.1. 5.5 series. Below
is mysqlnd @ 64bit @ MySQL 5.1.45.
Ulf
nixn...@linux-fuxh:~/php/php-src/branches/PHP_5_3_cta> sapi/cli/php
foo.php
array(1) {
["client_info"]=>
string(48) "mysqlnd 5.0.7-dev - 091210 - $Revision: 306939 $"
}
array(1) {
["server_info"]=>
string(12) "5.1.45-debug"
}
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Got a packet bigger than
'max_allowed_packet' bytes
[2011-01-06 14:20:01] u...@php.net
Please always add complete test. Never link external sites.
query('CREATE TABLE IF NOT EXISTS `test_bug_blob` (`id`
integer auto_increment, `data` BLOB, PRIMARY KEY(`id`));'))
die("Error creating table.\n");
if (!($result = $conn->query('SELECT @@max_allowed_packet')))
die("Error reading max allowed packet size.\n");
$max_allowed_packet = $result->fetch_array();
$max_allowed_packet = $max_allowed_packet[0];
if (!($stmt = $conn->prepare('INSERT INTO `test_bug_blob` (`data`)
VALUES (?)')))
die("Cannot prepare statement for INSERT. {$conn->error}\n");
// Sent blob smaller than max allowed_packet
$data = str_repeat('0123456789', $max_allowed_packet/20);
if (!$stmt->bind_param('s', $data))
die("Error binding parameters. {$stmt->error}\n");
if (!$stmt->execute())
die("Error executing prepared statement. {$stmt->error}\n");
echo "OK: Executed prepared statement with blob less than
max_allowed_packet.\n";
// Sent blob bigger than max allowed_packet
$big_data = str_repeat('0123456789', $max_allowed_packet/9);
$null = null;
if (!$stmt->bind_param('b', $null))
die("Error binding parameters. {$stmt->error}\n");
foreach(str_split($big_data, $max_allowed_packet) as $packet )
if (!$stmt->send_long_data(0, $packet))
die("Error sending long packet. {$stmt->error}\n");
if (!$stmt->execute())
die("Error executing prepared statement. {$stmt->error}\n");
echo "OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.\n";
[2010-12-20 17:56:32] jbreton at kronostechnologies dot com
I upgraded mysql to 5.1.54 using debian experimental packages and the
problem is
gone.
Hopefully it won't break my ubuntu setup, which was a brand new 10.10
using
official packages.
[2010-12-20 17:14:09] jbreton at kronostechnologes dot com
You haven't tried mysql5.1.49 which was specified in squarious'
description.
I just tried with php 5.3.4 stable and mysql5.1.49 without success.
[2010-12-20 17:14:07] jbreton at kronostechnologes dot com
You haven't tried mysql5.1.49 which was specified in squarious'
description.
I just tried with php 5.3.4 stable and mysql5.1.49 without success.
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/bug.php?id=53483
--
Edit this bug report at http://bugs.php.net/bug.php?id=53483&edit=1
Req #19974 [Asn->Wfx]: force close persistent SQL connections
Edit report at http://bugs.php.net/bug.php?id=19974&edit=1
ID: 19974
Updated by: and...@php.net
Reported by:artem at osp dot ru
Summary:force close persistent SQL connections
-Status: Assigned
+Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
Operating System: Linux
PHP Version:4.2.3
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Please use mysql_change_user() to reset the connection
Previous Comments:
[2011-01-06 17:20:28] u...@php.net
... don't think we should do anything on it. That magic new function is
mysql_change_user, its called by default with mysqli to clean up
connection, its exported in the mysqli API. People should just move
forward to mysqli.
[2002-10-21 02:53:14] artem at osp dot ru
You can call it function
'mysql_reset_connection' or 'mysql_pclose', as you like.
Of course, the target of this function is close those disadvantages,
which you list.
[2002-10-18 08:46:40] ge...@php.net
When you have a pclose, there is no need for pconnect, you
can also use mysql_connect.
Currently the problem is, that persistent connections in
MySQL have some disadvantages/bugs/problems:
- no unset for user variables
- session variables are not restored to global variables
- no unlock for tables
- unselect previous selected database
- temporary tables are not deleted
- ROLLBACK of not commited transactions
- SQL_FOUND_ROWS returns a valid result
currently MySQL AB works on a new api-function
mysql_reset_connection to fix all these things, so we have
to wait. Currently there is not enough functionality to
fix/handle this inside the mysql extension.
[2002-10-18 07:13:16] artem at osp dot ru
>From time to time I need close my SQL connections becose using Lock,
temporary tables, etc. But such code executed rare.
Can you add new function?
like:
bool mysql_pclose ([bool on_script_exit_or_now=FALSE,[resource
link_identifier]])
This function will allow easy using locks and temporary tables and do
not loose efficiency.
using this function can be such:
--
mysql_pconnent(...);
...
if(rare_case) {
mysql_pclose(TRUE); # close connect at exit
mysql_query("create temporary table ");
...
}
-
or such:
--
mysql_pconnent(...);
...
if(rare_case) {
mysql_query("create temporary table ");
...
mysql_pclose(); # close connect now
}
-
--
Edit this bug report at http://bugs.php.net/bug.php?id=19974&edit=1
Req #24350 [Asn->Wfx]: overloading mysqli-query-objects
Edit report at http://bugs.php.net/bug.php?id=24350&edit=1
ID: 24350
Updated by: and...@php.net
Reported by:webmaster at s0nix dot de
Summary:overloading mysqli-query-objects
-Status: Assigned
+Status: Wont fix
Type: Feature/Change Request
Package:MySQLi related
PHP Version:5CVS-2003-06-26 (dev)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
mysqli uses different paradigm. However, one can use foreach()/iterators
that are part of mysqli now to have something similar.
Previous Comments:
[2011-01-06 15:20:00] u...@php.net
Interesting, though MySQLi_Result object has some properties. This may
cause issues with results columns of the same name as existing object
properties (lengths, num_rows, current_field).
mysqli_result::fetch_object() works around that.
[2003-06-26 16:30:53] ge...@php.net
Assigned, but be aware, this will take some time.
1st) LinuxTag
2nd) MySQL License exceptions :)
3rd) fixing other bugs in ext/mysqli
4th) vacation
We will also have a db-maintainer meeting on LinuxTag, where we will
discuss about it (not only for mysqli...)
Regards
Georg
[2003-06-26 15:20:44] webmaster at s0nix dot de
Description:
The new mysqli-extension should use the object-overloading features of
PHP5 for a easier and cleaner access.
Reproduce code:
---
select_db("test");
$result = $mysql->query("SELECT CURRENT_USER() AS user");
while ($result->next())
{
echo $result->user;
}
$result->close();
$mysql->close();
?>
Expected result:
r...@localhost
--
Edit this bug report at http://bugs.php.net/bug.php?id=24350&edit=1
Req #47802 [Opn->Asn]: PDO_MYSQL doesn't use the charset parameter
Edit report at http://bugs.php.net/bug.php?id=47802&edit=1
ID: 47802
Updated by: ka...@php.net
Reported by:disbursement at dublin dot com
Summary:PDO_MYSQL doesn't use the charset parameter
-Status: Open
+Status: Assigned
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:5.2.9
-Assigned To:
+Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
Implemented in trunk for now
Previous Comments:
[2011-01-07 15:39:58] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307224
Log: Implemented FR #47802, support for character sets in DSN strings
for PDO_MYSQL
[2009-03-27 08:53:58] disbursement at dublin dot com
Description:
static int pdo_mysql_handle_factory(pdo_dbh_t *dbh, zval
*driver_options TSRMLS_DC) /* {{{ */
{
...
struct pdo_data_src_parser vars[] = {
{ "charset", NULL, 0 },
{ "dbname", "", 0 },
{ "host", "localhost",0 },
{ "port", "3306", 0 },
{ "unix_socket", PDO_MYSQL_UNIX_ADDR, 0 },
};
The option "charset"/vars[0] is never used, but would be a nice feature.
--
Edit this bug report at http://bugs.php.net/bug.php?id=47802&edit=1
Req #19974 [Wfx]: force close persistent SQL connections
Edit report at http://bugs.php.net/bug.php?id=19974&edit=1
ID: 19974
Updated by: u...@php.net
Reported by:artem at osp dot ru
Summary:force close persistent SQL connections
Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
Operating System: Linux
PHP Version:4.2.3
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
ext/mysql does not export mysql_change_user(). It cannot be called from
PHP. However, I agree with Won't fix.
Previous Comments:
[2011-01-07 15:36:18] and...@php.net
Please use mysql_change_user() to reset the connection
[2011-01-06 17:20:28] u...@php.net
... don't think we should do anything on it. That magic new function is
mysql_change_user, its called by default with mysqli to clean up
connection, its exported in the mysqli API. People should just move
forward to mysqli.
[2002-10-21 02:53:14] artem at osp dot ru
You can call it function
'mysql_reset_connection' or 'mysql_pclose', as you like.
Of course, the target of this function is close those disadvantages,
which you list.
[2002-10-18 08:46:40] ge...@php.net
When you have a pclose, there is no need for pconnect, you
can also use mysql_connect.
Currently the problem is, that persistent connections in
MySQL have some disadvantages/bugs/problems:
- no unset for user variables
- session variables are not restored to global variables
- no unlock for tables
- unselect previous selected database
- temporary tables are not deleted
- ROLLBACK of not commited transactions
- SQL_FOUND_ROWS returns a valid result
currently MySQL AB works on a new api-function
mysql_reset_connection to fix all these things, so we have
to wait. Currently there is not enough functionality to
fix/handle this inside the mysql extension.
[2002-10-18 07:13:16] artem at osp dot ru
>From time to time I need close my SQL connections becose using Lock,
temporary tables, etc. But such code executed rare.
Can you add new function?
like:
bool mysql_pclose ([bool on_script_exit_or_now=FALSE,[resource
link_identifier]])
This function will allow easy using locks and temporary tables and do
not loose efficiency.
using this function can be such:
--
mysql_pconnent(...);
...
if(rare_case) {
mysql_pclose(TRUE); # close connect at exit
mysql_query("create temporary table ");
...
}
-
or such:
--
mysql_pconnent(...);
...
if(rare_case) {
mysql_query("create temporary table ");
...
mysql_pclose(); # close connect now
}
-
--
Edit this bug report at http://bugs.php.net/bug.php?id=19974&edit=1
Bug #53679 [Bgs]: Array are reference by copying to another array, after bind_param()
Edit report at http://bugs.php.net/bug.php?id=53679&edit=1 ID: 53679 User updated by:mail at andreas-rex dot de Reported by:mail at andreas-rex dot de Summary:Array are reference by copying to another array, after bind_param() Status: Bogus Type: Bug Package:MySQLi related PHP Version:5.2.17 Block user comment: N Private report: N New Comment: Sorry, for my bug posting, It's has nothing to do with bind_param(). Can somebody close ii? Or is it already closed? Previous Comments: [2011-01-07 08:53:56] mail at andreas-rex dot de It like this example on http://www.php.net/manual/en/language.references.whatdo.php you mentioned: [2011-01-06 22:42:31] cataphr...@php.net This is not a bug, it's a consequence of how references and arrays work in PHP (perhaps, more appropriately, this is a bug, but a it's a design shortcoming that can't be fixed any time soon). Take a look at http://www.php.net/manual/en/language.references.whatdo.php [2011-01-06 22:21:00] mail at andreas-rex dot de Description: When an array was in a parameter list from bind_param() you can't copy it to another array, it's always a reference. But when you copy a single field from this array to a variable it's not a refence to the array. Test script: --- http://www.madking.de/bind_param_and_array.txt Expected result: Some Examples, which show what I mean. It's bit hard to understand. It's NOT the reference to bind_param(). It's that an array gives only his reference when copied to another array. -- Edit this bug report at http://bugs.php.net/bug.php?id=53679&edit=1
Bug #53658 [Fbk->Csd]: is_writable returns always false
Edit report at http://bugs.php.net/bug.php?id=53658&edit=1
ID: 53658
User updated by:pierregobin at free dot fr
Reported by:pierregobin at free dot fr
Summary:is_writable returns always false
-Status: Feedback
+Status: Closed
Type: Bug
Package:Filesystem function related
Operating System: Linux 2.6.35
PHP Version:5.3SVN-2011-01-05 (SVN)
Block user comment: N
Private report: N
New Comment:
yes this is related to selinux : disabling selinux makes it work
correctly.
Previous Comments:
[2011-01-06 23:27:07] ras...@php.net
Nah, this is pure Unix permissions. You are missing a piece somewhere.
PHP
doesn't do anything magical here. selinux perhaps. Dunno. strace a
request and
see which low-level syscall is failing here.
[2011-01-06 23:21:10] pierregobin at free dot fr
Hi -
1) apache is the user as shown by ps aux | grep httpd.
apache1724 0.0 0.8 33996 4248 ?S18:00 0:00
/usr/sbin/httpd
apache1726 0.0 0.6 32972 3292 ?S18:00 0:00
/usr/sbin/httpd
2) when I run php on command line using my own account :
php -f is_writable.php - result is correct;
3) when I run php on command line sudoed by apache - it works also (echo
is_writable).
sudo -u apache php -f is_writable.php
this echos the right result :
is_writable
Seems like httpd is disturbing php...
[2011-01-05 23:44:23] ras...@php.net
Are you absolutely sure your web server is running as user apache? Do a
"ps -aux
| grep httpd" or "ps aux | grep apache" and see which user it is running
as.
is_writable works fine everywhere as far as I know.
[2011-01-05 22:38:05] pierregobin at free dot fr
Description:
When php script is run via apache is_writable always returns false :
'is_writable()' always returns 'false' whatever :
- the permission write sets or not.
- safe_mode on or off
- the owner of the file being root:root or apache:apache
on the other side, 'is_readable()' returns the correct value (either
'true' when the file is made readable or 'false' when the file is made
unreadable).
But, when the same script is run by the php command line (under root) -
is_writable returns the correct value.
Test script:
---
";
} else {
echo "is not writable!!!";
}
?>
Expected result:
is_writable in case 'toto' is writable
is not writable in case 'toto' is not writable
--
Edit this bug report at http://bugs.php.net/bug.php?id=53658&edit=1
[PHP-BUG] Bug #53689 [NEW]: Installer fails to enter PHP-path into httpd.conf
From: Operating system: Windows 7 32-Bit PHP version: 5.3.5 Package: Windows Installer Bug Type: Bug Bug description:Installer fails to enter PHP-path into httpd.conf Description: Use the VC6 x86 Thread Safe installer (downloaded from http://windows.php.net/download/) to install PHP 5.3.5 as an Apache 2.2 module. When installing, the httpd.conf is modified, but it leaves the path blank: BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir "" LoadModule php5_module "php5apache2_2.dll" #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL instead of BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir "C:/Program Files/PHP/" LoadModule php5_module "C:/Program Files/PHP/php5apache2_2.dll" #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL -- Edit bug report at http://bugs.php.net/bug.php?id=53689&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53689&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53689&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53689&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53689&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53689&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53689&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53689&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53689&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53689&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53689&r=support Expected behavior: http://bugs.php.net/fix.php?id=53689&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53689&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53689&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53689&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53689&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53689&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53689&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53689&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53689&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53689&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53689&r=mysqlcfg
Req #39847 [Asn]: mysqli_fetch_[field|fields|field_direct] need to return db
Edit report at http://bugs.php.net/bug.php?id=39847&edit=1 ID: 39847 Updated by: ka...@php.net Reported by:marzillo at emdeon dot com Summary:mysqli_fetch_[field|fields|field_direct] need to return db Status: Assigned Type: Feature/Change Request Package:MySQLi related Operating System: * PHP Version:5.2.0 -Assigned To:mysql +Assigned To:kalle Block user comment: N Private report: N New Comment: I implemented this in trunk for mysqli, keeping this open until its decided whether this should be merged to 5.3 Previous Comments: [2011-01-07 19:25:57] ka...@php.net Automatic comment from SVN on behalf of kalle Revision: http://svn.php.net/viewvc/?view=revision&revision=307231 Log: Implemented FR #39847 (mysqli_fetch_[field|fields|field_direct] need to return db) [2011-01-06 14:53:24] u...@php.net Andrey? Sounds like a valid request... let's do [2006-12-15 19:51:36] marzillo at emdeon dot com Description: The mysqli functions fetch_field, fetch_fields and fetch_field_direct do not return the db name when the C API allows it. For the past several versions I have been adding the following code to mysqli_api.c to include this field. Could this be included in future releases? mysqli_fetch_field function add_property_string(return_value, "db",(field->db ? field->db : ""), 1); mysqli_fetch_fields function add_property_string(obj, "db",(field->db ? field->db : ""), 1); mysqli_fetch_field_direct add_property_string(return_value, "db",(field->db ? field->db : ""), 1); -- Edit this bug report at http://bugs.php.net/bug.php?id=39847&edit=1
Req #48482 [Opn->Asn]: add $is_html optional parameter to highlight_*
Edit report at http://bugs.php.net/bug.php?id=48482&edit=1 ID: 48482 Updated by: ka...@php.net Reported by:php dot net at fuscata dot com Summary:add $is_html optional parameter to highlight_* -Status: Open +Status: Assigned Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Linux PHP Version:5.2.9 -Assigned To: +Assigned To:kalle Block user comment: N Private report: N New Comment: I added the $is_xhtml parameter to nl2br() back in 5.3, I can probably cook up a patch for this aswell :) Previous Comments: [2009-06-05 17:22:45] php dot net at fuscata dot com Description: highlight_string() and highlight_file() return XHTML code. Please add the optional parameter $is_xhtml similar to nl2br(). -- Edit this bug report at http://bugs.php.net/bug.php?id=48482&edit=1
Bug #53679 [Bgs]: Array are reference by copying to another array, after bind_param()
Edit report at http://bugs.php.net/bug.php?id=53679&edit=1 ID: 53679 Updated by: cataphr...@php.net Reported by:mail at andreas-rex dot de Summary:Array are reference by copying to another array, after bind_param() Status: Bogus Type: Bug Package:MySQLi related PHP Version:5.2.17 Block user comment: N Private report: N New Comment: Yes, that was the relevant part. And the bug is already closed. Thank you interest in PHP nonetheless. Previous Comments: [2011-01-07 17:59:53] mail at andreas-rex dot de Sorry, for my bug posting, It's has nothing to do with bind_param(). Can somebody close ii? Or is it already closed? [2011-01-07 08:53:56] mail at andreas-rex dot de It like this example on http://www.php.net/manual/en/language.references.whatdo.php you mentioned: [2011-01-06 22:42:31] cataphr...@php.net This is not a bug, it's a consequence of how references and arrays work in PHP (perhaps, more appropriately, this is a bug, but a it's a design shortcoming that can't be fixed any time soon). Take a look at http://www.php.net/manual/en/language.references.whatdo.php [2011-01-06 22:21:00] mail at andreas-rex dot de Description: When an array was in a parameter list from bind_param() you can't copy it to another array, it's always a reference. But when you copy a single field from this array to a variable it's not a refence to the array. Test script: --- http://www.madking.de/bind_param_and_array.txt Expected result: Some Examples, which show what I mean. It's bit hard to understand. It's NOT the reference to bind_param(). It's that an array gives only his reference when copied to another array. -- Edit this bug report at http://bugs.php.net/bug.php?id=53679&edit=1
Bug->Req #53666 [Opn]: local static variables in methods tied to the object instance
Edit report at http://bugs.php.net/bug.php?id=53666&edit=1 ID: 53666 Updated by: cataphr...@php.net Reported by:crystal at cyclonephp dot com -Summary:local static variables in methods handled incorrectly +Summary:local static variables in methods tied to the object instance Status: Open -Type: Bug +Type: Feature/Change Request Package:Scripting Engine problem Operating System: linux PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Why? At most this is a (bc breaking) feature request. Function static variables have always been tied only with the function itself. Previous Comments: [2011-01-06 12:40:16] crystal at cyclonephp dot com Description: The inital value of a static variable in a non-static method should take care about the current instance. The initialization should be done when a method of the instance is called, and not only when the method is first called in the script. The local static variable should be interpreted as an object variable that is visible only in the declaring method. Test script: --- statvartest(); $testA->statvartest(); $testB = new StatTest; $testB->statvartest(); $testB->statvartest(); Expected result: initial changed initial changed Actual result: -- initial changed changed changed -- Edit this bug report at http://bugs.php.net/bug.php?id=53666&edit=1
Req #53666 [Opn]: local static variables in methods tied to the object instance
Edit report at http://bugs.php.net/bug.php?id=53666&edit=1 ID: 53666 User updated by:crystal at cyclonephp dot com Reported by:crystal at cyclonephp dot com Summary:local static variables in methods tied to the object instance Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: linux PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Because this way local static variables can't be used eg. for caching method return values. I think it's a very important use case. I also don't think that it would cause severe bc issues. Previous Comments: [2011-01-07 21:52:18] cataphr...@php.net Why? At most this is a (bc breaking) feature request. Function static variables have always been tied only with the function itself. [2011-01-06 12:40:16] crystal at cyclonephp dot com Description: The inital value of a static variable in a non-static method should take care about the current instance. The initialization should be done when a method of the instance is called, and not only when the method is first called in the script. The local static variable should be interpreted as an object variable that is visible only in the declaring method. Test script: --- statvartest(); $testA->statvartest(); $testB = new StatTest; $testB->statvartest(); $testB->statvartest(); Expected result: initial changed initial changed Actual result: -- initial changed changed changed -- Edit this bug report at http://bugs.php.net/bug.php?id=53666&edit=1
[PHP-BUG] Bug #53690 [NEW]: 5.2svn: swapped memset arguments in struct initialization
From: Operating system: Linux PHP version: 5.2SVN-2011-01-08 (SVN) Package: Zip Related Bug Type: Bug Bug description:5.2svn: swapped memset arguments in struct initialization Description: This is already fixed in 5.3svn (see bug #53568). Please backport the fix to 5.2svn: memset(&tm, sizeof(tm), 0); causes: ext/zip/lib/zip_dirent.o: In function `memset': /usr/include/bits/string3.h:83: warning: memset used with constant zero length parameter; this could be due to transposed parameters -- Edit bug report at http://bugs.php.net/bug.php?id=53690&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53690&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53690&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53690&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53690&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53690&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53690&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53690&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53690&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53690&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53690&r=support Expected behavior: http://bugs.php.net/fix.php?id=53690&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53690&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53690&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53690&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53690&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53690&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53690&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53690&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53690&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53690&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53690&r=mysqlcfg
Req #48352 [Com]: Method registerNodeClass does not work with DOMNodeList
Edit report at http://bugs.php.net/bug.php?id=48352&edit=1
ID: 48352
Comment by: mat at homedvd dot ca
Reported by:php at xxlwebdesign dot de
Summary:Method registerNodeClass does not work with
DOMNodeList
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Gentoo
PHP Version:5.3CVS-2009-05-21 (snap)
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
Any movement on this? The method should probably be called
registerNodeListClass
Previous Comments:
[2010-02-15 02:45:10] mail at r-site dot net
very helpfull, extending DOMNode's almost implies it, pls hurry, ty
[2009-09-20 21:17:12] goetas at lignano dot it
this would be really helpful!
[2009-05-22 12:53:55] php at xxlwebdesign dot de
This would be very nice!
[2009-05-22 10:49:41] rricha...@php.net
This method was designed specifically for DOMNode based classes only.
changing to feature request and I will consider and evaluate expanding
its functionality.
[2009-05-21 09:38:59] php at xxlwebdesign dot de
Description:
The method DOMDocument->registerNodeClass does not work with DOMNodeList
Reproduce code:
---
registerNodeClass('DOMNodeList', 'MyNodeList');
?>
Actual result:
--
Fatal error: DOMDocument::registerNodeClass() [domdocument.registernodeclass]:
Class DOMNodeList is not derived from DOMNode. in ...
--
Edit this bug report at http://bugs.php.net/bug.php?id=48352&edit=1
[PHP-BUG] Req #53693 [NEW]: transformToDoc, different class
From:
Operating system: Any
PHP version: Irrelevant
Package: XSLT related
Bug Type: Feature/Change Request
Bug description:transformToDoc, different class
Description:
It would be very helpful to allow transformToDoc to return a custom class
instance, which would have to extend DOMDocument of course.
The example code provided is simplified. Far better usage could be made
from the child DOMDocument class -- this is only an example to illustrate
the potential.
Test script:
---
class DOMDocumentYouCanFancyPrint extends DOMDocument {
public function __toString() {
return "" . htmlentities( $this->saveXML() ) . "";
}
}
...
$processor->registerDocumentClass( "DOMDocumentYouCanFancyPrint" );
echo $processor->transformToDoc( $sourceDOM );
Expected result:
The expected result would be that the transformToDoc method call returns an
instance of DOMDocumentYouCanFancyPrint.
--
Edit bug report at http://bugs.php.net/bug.php?id=53693&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53693&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53693&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53693&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53693&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53693&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53693&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53693&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53693&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53693&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53693&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53693&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53693&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53693&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53693&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53693&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53693&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53693&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53693&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53693&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53693&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53693&r=mysqlcfg
Bug #53578 [Csd]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 User updated by:tanguy dot pruvot at gmail dot com Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Closed Type: Bug Package:cURL related Operating System: Win7/Vista x86 PHP Version:5.3.4 (Since 5.2.14/5.3) Assigned To:pajoye Block user comment: N Private report: N New Comment: 5.3.5 (vc6 ts) is affected too :( look like the libcurl was not updated... Previous Comments: [2010-12-28 12:07:05] paj...@php.net See http://sourceforge.net/tracker/index.php?func=detail&aid=3140533&group_id=976&atid=100976 [2010-12-28 12:07:02] paj...@php.net See http://sourceforge.net/tracker/index.php?func=detail&aid=3140533&group_id=976&atid=100976 [2010-12-28 12:06:50] paj...@php.net My patch has been applied upstream as well now. Let close this one (both versions are fixed). [2010-12-20 13:38:31] tanguy dot pruvot at gmail dot com Hmm no, in fact i use mod_fcgid for another CGI... WDScript :) since 2010 http://sourceforge.net/apps/trac/wdscript/attachment/wiki/FastCGI/ProtocoleFastCGI .png PHP was used as apache module, to skip this kind of bug and reduce loading times ;) But i will also try a switch, now mod_fcgid seems stable on Win32 too ;) [2010-12-20 13:21:41] paj...@php.net If you use fcgid with apache, then you can use VC9 php builds right now, without switching to a VC9 apache. 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/bug.php?id=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
Bug #53578 [Csd]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 User updated by:tanguy dot pruvot at gmail dot com Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Closed Type: Bug Package:cURL related Operating System: Win7/Vista x86 -PHP Version:5.3.4 (Since 5.2.14/5.3) +PHP Version:5.3.5 (Since 5.2.14/5.3) Assigned To:pajoye Block user comment: N Private report: N New Comment: Here is the patched php_curl.dll for VC6 TS (for PHP as Apache Module) http://tanguy.wdscript.fr/?q=system/files/php_curl.535vc6ts.Patch_.zip Previous Comments: [2011-01-08 08:03:24] tanguy dot pruvot at gmail dot com 5.3.5 (vc6 ts) is affected too :( look like the libcurl was not updated... [2010-12-28 12:07:05] paj...@php.net See http://sourceforge.net/tracker/index.php?func=detail&aid=3140533&group_id=976&atid=100976 [2010-12-28 12:07:02] paj...@php.net See http://sourceforge.net/tracker/index.php?func=detail&aid=3140533&group_id=976&atid=100976 [2010-12-28 12:06:50] paj...@php.net My patch has been applied upstream as well now. Let close this one (both versions are fixed). [2010-12-20 13:38:31] tanguy dot pruvot at gmail dot com Hmm no, in fact i use mod_fcgid for another CGI... WDScript :) since 2010 http://sourceforge.net/apps/trac/wdscript/attachment/wiki/FastCGI/ProtocoleFastCGI .png PHP was used as apache module, to skip this kind of bug and reduce loading times ;) But i will also try a switch, now mod_fcgid seems stable on Win32 too ;) 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/bug.php?id=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
