Bug #51316 [Asn-Csd]: Undefined first referenced symbol in file mysql_set_character_set ext/mysql/.li
Edit report at http://bugs.php.net/bug.php?id=51316edit=1 ID: 51316 Updated by: u...@php.net Reported by:andressucer at gmail dot com Summary:Undefined first referenced symbol in file mysql_set_character_set ext/mysql/.li -Status: Assigned +Status: Closed Type: Bug Package:Compile Failure Operating System: Solaris PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: If I'm not mistaken the reporter says the problem is solved. Closing. Previous Comments: [2010-09-30 17:40:41] andressucer at gmail dot com thank you Adrian the problem was solved the installation was successfully completed with the following configuration: export PATH=/aplicaciones/pgsql843:/usr/local/:/aplicaciones/mysql5136/:/aplicaciones/l ibxml2- 2.6.31/:/aplicaciones/zlib/lib/:/usr/local/lib/:/usr/ccs/bin/:/usr/sfw/bin/:/usr /sbin/:/usr/bin/:/bin:/sbin/:/usr/local/bin:/opt/csw/bin:/usr/sfw/bin export LD_LIBRARY_PATH=/usr/local/:/aplicaciones/mysql5136/:/aplicaciones/zlib/lib/:/us r/local/lib/:/usr/lib/:/lib/:/usr/local/include/:/aplicaciones/libxml2- 2.6.31/:/usr/sfw/lib:/opt/sfw/lib:/usr/local/lib ./configure --prefix=/aplicaciones/phpmysql -with-mysql=/aplicaciones/mysql5136/ --with-apxs2=/aplicaciones/apachemysql/bin/apxs --with- pgsql=/aplicaciones/pgsql843 --enable-ftp --enable-mbstring --with- gd=/aplicaciones/gd-2.0.35 --with-jpeg-dir=/aplicaciones/jpeg-6b --with- zlib=/aplicaciones/zlib --with-curl=/aplicaciones/curl --with-config-file- path=/aplicaciones/phpmysql --with-freetype-dir=/aplicaciones/freetype-2.3.1 -- with-openssl=/aplicaciones/openssl --enable-soap --with-readline --with-xmlrpc --enable-zip --with-pear --enable-sockets --with-ttf make make install [2010-09-29 22:08:24] lobosoli at gmail dot com If you have solaris 10, you have to remove the mysql of the system with this commands pkgrm SUNWmysqlr pkgrm SUNWmysqlt pkgrm SUNWmysqlu [2010-04-16 18:20:01] progmanpaul at gmail dot com If you omit --with-openssl then the GD Lib portion fails because it requires libssl - FYI. [2010-03-31 03:33:40] gene at neckosoft dot com I have the same problem. Here's my configure options: ./configure --prefix=/apps/local/phpdev --with-curl=/apps/local/curl --with-openssl=/apps/local/openssl \ --with-mysql=/apps/local/mysql-5.1.45-solaris10-sparc --with-apxs2=/usr/apache2/bin/apxs -âwith-readline=/opt/sfw and here's the error I am getting: Undefined first referenced symbol in file mysql_set_character_set ext/mysql/.libs/php_mysql.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sapi/cli/php' [2010-03-21 20:48:09] hholz...@php.net Does this also happen when not using -with-openssl ? Seems to be similar to http://www.phpfreaks.com/forums/index.php?topic=170577.0 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=51316 -- Edit this bug report at http://bugs.php.net/bug.php?id=51316edit=1
Bug #50318 [Asn-Bgs]: multiple statments result exception
Edit report at http://bugs.php.net/bug.php?id=50318edit=1
ID: 50318
Updated by: u...@php.net
Reported by:yury at nix dot co dot il
Summary:multiple statments result exception
-Status: Assigned
+Status: Bogus
Type: Bug
Package:PDO related
Operating System: FreeBSD 7.2-STABLE
PHP Version:5.2.11
Assigned To:mysql
Block user comment: N
New Comment:
PHP 5.2 is EOL'd. Use PHP 5.3
http://www.php.net/archive/2010.php#id2010-07-22-1
The PHP development team would like to announce the immediate
availability of PHP 5.2.14. This release focuses on improving the
stability of the PHP 5.2.x branch with over 60 bug fixes, some of which
are security related.
This release marks the end of the active support for PHP 5.2. *Following
this release the PHP 5.2 series will receive no further active bug
maintenance.* Security fixes for PHP 5.2 might be published on a case by
cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3
Previous Comments:
[2009-11-28 12:18:29] yury at nix dot co dot il
I have just checked out the code of mysql_driver.c in 5_3,
it seems that the issue handled there, however I do not understand why
to
mysql_store_result() and then mysql_free_result(), it seems to work with
my solution as well... ( checked only on 5.2.11 )
[2009-11-28 12:08:55] yury at nix dot co dot il
Description:
When using multiple statments in a single $pdo-execute(),
php throws an exception, however the staments bieng executed anyway.
( example: http://pastebin.com/f6aec645c )
I think the mysql server expects the resultset to be advanced even if
it's empty, as shown in the c-api example here:
http://dev.mysql.com/doc/refman/5.1/en/c-api-multiple-queries.html
I think the follwing will resolve the issue
( diff against svn 5_2 )
*** mysql_driver.c Sat Nov 28 13:13:07 2009
--- /home/yury/php-5.2.11/ext/pdo_mysql/mysql_driver.c Fri Nov 27
13:55:46 2009
***
*** 252,261
--- 252,262
my_ulonglong c = mysql_affected_rows(H-server);
if (c == (my_ulonglong) -1) {
pdo_mysql_error(dbh);
return (H-einfo.errcode ? -1 : 0);
} else {
+ while ( 0 == mysql_next_result( H-server ) );
return c;
}
}
}
Reproduce code:
---
http://pastebin.com/f6aec645c
Expected result:
throw exception and not commit
-or-
commit and not throw exception
Actual result:
--
The follwing exception thrown:
SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other
unbuffered queries are active. Consider using PDOStatement::fetchAll().
Alternatively, if your code is only ever going to run against mysql,
you may enable query buffering by setting the
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
But the data IS commited to the database.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50318edit=1
Req #48587 [Asn]: MySQL PDO driver doesn't support SSL connections
Edit report at http://bugs.php.net/bug.php?id=48587edit=1 ID: 48587 Updated by: u...@php.net Reported by:michael dot stringer at yuuguu dot com Summary:MySQL PDO driver doesn't support SSL connections Status: Assigned Type: Feature/Change Request Package:PDO related Operating System: * PHP Version:5.2.9 Assigned To:mysql Block user comment: N New Comment: 5.2 is closed, http://www.php.net/archive/2010.php#id2010-07-22-1 The PHP development team would like to announce the immediate availability of PHP 5.2.14. This release focuses on improving the stability of the PHP 5.2.x branch with over 60 bug fixes, some of which are security related. This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance. Security fixes for PHP 5.2 might be published on a case by cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3 Previous Comments: [2009-06-17 15:55:44] michael dot stringer at yuuguu dot com Description: The mysqli driver supports connecting to MySQL databases using SSL certificates via the ssl_set command (which in turn calls the native client ssl_set function). Please add this functionality to the PDO driver. This is currently preventing us from switching from the mysqli APIs to PDO. -- Edit this bug report at http://bugs.php.net/bug.php?id=48587edit=1
Bug #36073 [Asn-Wfx]: Source-compiled MySQL on x86_64 causes PHP configure failure
Edit report at http://bugs.php.net/bug.php?id=36073edit=1 ID: 36073 Updated by: and...@php.net Reported by:chris at spawnordie dot com Summary:Source-compiled MySQL on x86_64 causes PHP configure failure -Status: Assigned +Status: Wont fix Type: Bug Package:MySQL related Operating System: Linux/Any PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: ext/mysql has been deprecated in favor of ext/mysqli. ext/mysqli gets only security fixes. Either use the workaround or switch to using mysqlnd. Previous Comments: [2010-06-06 08:10:43] phi...@php.net Looks like a bug. [2010-06-06 02:29:11] everyminutepies at yahoo dot ca I can confirm that this does in fact still happen with PHP 5.3.2 on CentOS 5.5 86_64 when compiling MySQL 5.0.xx and PHP on a standard installation. Despite being told by the configuration option --with-libdir=lib64 to use lib64/ it still chooses to use lib/ and fails to find the necessary files to continue with the ./configure. The posted workaround by Chris does work flawlessly. I invite the reviewer to explain either why the documentation is incorrect about the function of --with-libdir or why it is not respected in regards to mysql at his leisure. Trustfully, I agree not to become enraged when he suggests I know nothing about computers and post an enraged rant about him in the year 2014. ./configure --prefix=/usr/local/secure/php --with-apxs2=/usr/local/secure/apache2/bin/apxs --with-mysql=/usr/local/mysql/ --with-libdir=lib64 [2010-03-25 23:16:19] chris at spawnordie dot com Other than the bug reviewer just being a flat-out ass... It is still a bug in PHP. The PHP configure process honors the --with-libdir value for PostgreSQL and many, many other packages, but NOT for its check of MySQL. It is NOT a bug in MySQL, which installs its libraries in lib64, just like every other application that is compiled for 64bit OS. But PHP somehow magically knows how to find all of those other applications. At the very least, it is an inconsistency that could have been cleaned up with 15 minutes of effort by the PHP team when I reported the bug 4 years ago! And, based on the fact that I provided a work-around, it should have been clear that I did, in fact, know what I was doing. Maybe my feelings were a little hurt, but there's no excuse for the rudeness this bug reviewer showed. I sincerely hope that he/she is no longer in that role -- or doing anything that requires using any level of tact with actual people -- because he/she is just a jerk and is in serious need of therapy. Maybe he/she didn't get hugged as a child and is displaying a superiority complex to cover up low self-esteem and fear of being hurt. But I digress. [2010-03-25 18:32:22] michael at michaelsnet dot us IMHO this is a documentation bug. Consider adding a README.64bit file containing this information and other relevant information. [2006-01-18 23:53:50] sni...@php.net Works fine for me. Hint: Don't try building Mysql yourself if you don't know how to do it properly. Use the binary packages provided by MySQL. And last but not least: report this to MySQL. It's not our fault if they do things wrong. 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=36073 -- Edit this bug report at http://bugs.php.net/bug.php?id=36073edit=1
Bug #36073 [Wfx]: Source-compiled MySQL on x86_64 causes PHP configure failure
Edit report at http://bugs.php.net/bug.php?id=36073edit=1 ID: 36073 Updated by: and...@php.net Reported by:chris at spawnordie dot com Summary:Source-compiled MySQL on x86_64 causes PHP configure failure Status: Wont fix Type: Bug Package:MySQL related Operating System: Linux/Any PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: Erm, I meant that ext/mysql gets only security fixes. Previous Comments: [2010-10-28 09:50:05] and...@php.net ext/mysql has been deprecated in favor of ext/mysqli. ext/mysqli gets only security fixes. Either use the workaround or switch to using mysqlnd. [2010-06-06 08:10:43] phi...@php.net Looks like a bug. [2010-06-06 02:29:11] everyminutepies at yahoo dot ca I can confirm that this does in fact still happen with PHP 5.3.2 on CentOS 5.5 86_64 when compiling MySQL 5.0.xx and PHP on a standard installation. Despite being told by the configuration option --with-libdir=lib64 to use lib64/ it still chooses to use lib/ and fails to find the necessary files to continue with the ./configure. The posted workaround by Chris does work flawlessly. I invite the reviewer to explain either why the documentation is incorrect about the function of --with-libdir or why it is not respected in regards to mysql at his leisure. Trustfully, I agree not to become enraged when he suggests I know nothing about computers and post an enraged rant about him in the year 2014. ./configure --prefix=/usr/local/secure/php --with-apxs2=/usr/local/secure/apache2/bin/apxs --with-mysql=/usr/local/mysql/ --with-libdir=lib64 [2010-03-25 23:16:19] chris at spawnordie dot com Other than the bug reviewer just being a flat-out ass... It is still a bug in PHP. The PHP configure process honors the --with-libdir value for PostgreSQL and many, many other packages, but NOT for its check of MySQL. It is NOT a bug in MySQL, which installs its libraries in lib64, just like every other application that is compiled for 64bit OS. But PHP somehow magically knows how to find all of those other applications. At the very least, it is an inconsistency that could have been cleaned up with 15 minutes of effort by the PHP team when I reported the bug 4 years ago! And, based on the fact that I provided a work-around, it should have been clear that I did, in fact, know what I was doing. Maybe my feelings were a little hurt, but there's no excuse for the rudeness this bug reviewer showed. I sincerely hope that he/she is no longer in that role -- or doing anything that requires using any level of tact with actual people -- because he/she is just a jerk and is in serious need of therapy. Maybe he/she didn't get hugged as a child and is displaying a superiority complex to cover up low self-esteem and fear of being hurt. But I digress. [2010-03-25 18:32:22] michael at michaelsnet dot us IMHO this is a documentation bug. Consider adding a README.64bit file containing this information and other relevant information. 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=36073 -- Edit this bug report at http://bugs.php.net/bug.php?id=36073edit=1
[PHP-BUG] Bug #53190 [NEW]: glob() always return empty array
From: Operating system: Linux Debian PHP version: 5.2SVN-2010-10-28 (snap) Package: Filesystem function related Bug Type: Bug Bug description:glob() always return empty array Description: test is simple: print_r(glob(/var/www/*)); Always returns empty array. Yes, I know this is strange, yes I have search whole web and no solution yet. Problem is probably related to OS, because other server (also linux lenny) work OK on the same apache2 and same php5 module. I have made simple command line test: sudo -u www-data php5 -c /etc/php5/apache2/php.ini -r 'print_r(glob(/var/www/*));' And this is working OK. My apache2 has no strange modules, this is normal web server. My system: php5: 5.2.6.dfsg.1-1+lenny9 kernel: 2.6.8-2-386 libc6: 2.7-18lenny6 apache: apache2 2.2.9-10+lenny8 No special file system security on OS, /var/www is 777, default apache2 security settings. This problem is VERY rare, but Im not the only one: same problem here: http://forums.gentoo.org/viewtopic-t-826894-start-0.html Any suggestions? PLEASE HELP! Test script: --- print_r(glob(/var/www/*)); Expected result: glob() should return array of files Actual result: -- empty array, no errors -- Edit bug report at http://bugs.php.net/bug.php?id=53190edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53190r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53190r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53190r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53190r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53190r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53190r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53190r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53190r=needscript Try newer version: http://bugs.php.net/fix.php?id=53190r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53190r=support Expected behavior: http://bugs.php.net/fix.php?id=53190r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53190r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53190r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53190r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53190r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53190r=dst IIS Stability: http://bugs.php.net/fix.php?id=53190r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53190r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53190r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53190r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53190r=mysqlcfg
[PHP-BUG] Bug #53191 [NEW]: var_dump a regex failes
From:
Operating system: Windows XP SP3
PHP version: 5.3.3
Package: Strings related
Bug Type: Bug
Bug description:var_dump a regex failes
Description:
When i run the code i get a wrong result. var_dump stops outputting but i
don't know why.
Test script:
---
?php
var_dump('#(?![\p{Nd}\p{L}_])(test)(?![\p{Nd}\p{L}_])#iu');
?
Expected result:
string(47) #(?![\p{Nd}\p{L}_])(test)(?![\p{Nd}\p{L}_])#iu
Actual result:
--
string(47) #(?
--
Edit bug report at http://bugs.php.net/bug.php?id=53191edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53191r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53191r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53191r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53191r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53191r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53191r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53191r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53191r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53191r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53191r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53191r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53191r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53191r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53191r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53191r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53191r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53191r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53191r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53191r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53191r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53191r=mysqlcfg
Bug #53191 [Opn-Bgs]: var_dump a regex failes
Edit report at http://bugs.php.net/bug.php?id=53191edit=1
ID: 53191
Updated by: sala...@php.net
Reported by:michelmulder at gmail dot com
Summary:var_dump a regex failes
-Status: Open
+Status: Bogus
Type: Bug
Package:Strings related
Operating System: Windows XP SP3
PHP Version:5.3.3
Block user comment: N
New Comment:
Looks like you're viewing the page as HTML. View the source, or send it
out as
plain text. Not a bug.
Previous Comments:
[2010-10-28 14:07:12] michelmulder at gmail dot com
Description:
When i run the code i get a wrong result. var_dump stops outputting but
i don't know why.
Test script:
---
?php
var_dump('#(?![\p{Nd}\p{L}_])(test)(?![\p{Nd}\p{L}_])#iu');
?
Expected result:
string(47) #(?![\p{Nd}\p{L}_])(test)(?![\p{Nd}\p{L}_])#iu
Actual result:
--
string(47) #(?
--
Edit this bug report at http://bugs.php.net/bug.php?id=53191edit=1
Bug #53191 [Bgs]: var_dump a regex failes
Edit report at http://bugs.php.net/bug.php?id=53191edit=1
ID: 53191
User updated by:michelmulder at gmail dot com
Reported by:michelmulder at gmail dot com
Summary:var_dump a regex failes
Status: Bogus
Type: Bug
Package:Strings related
Operating System: Windows XP SP3
PHP Version:5.3.3
Block user comment: N
New Comment:
Hi,
When i'm viewing the source, the result is still not as expected. But
when i send a text/plain header i get the right result. I think it's a
bug in FireFox.
Thank you for your answer and sorry for wasting your time.
Previous Comments:
[2010-10-28 14:15:31] sala...@php.net
Looks like you're viewing the page as HTML. View the source, or send it
out as
plain text. Not a bug.
[2010-10-28 14:07:12] michelmulder at gmail dot com
Description:
When i run the code i get a wrong result. var_dump stops outputting but
i don't know why.
Test script:
---
?php
var_dump('#(?![\p{Nd}\p{L}_])(test)(?![\p{Nd}\p{L}_])#iu');
?
Expected result:
string(47) #(?![\p{Nd}\p{L}_])(test)(?![\p{Nd}\p{L}_])#iu
Actual result:
--
string(47) #(?
--
Edit this bug report at http://bugs.php.net/bug.php?id=53191edit=1
[PHP-BUG] Bug #53192 [NEW]: SimpleXML ignores XSI:TYPE attributes
From:
Operating system: Windows 7 64bit
PHP version: 5.3.3
Package: SimpleXML related
Bug Type: Bug
Bug description:SimpleXML ignores XSI:TYPE attributes
Description:
Hello,
It seems that SimpleXML removed all references to xsi:type in every node.
XML Parser does show the xsi:type as an attribute.
The code below demonstrates this.
Test script:
---
$xmlData = 'root xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
node xsi:type=TestDATA/node/root';
// Try First with SimpleXml
$xml = simplexml_load_string($xmlData);
echo Node XSI:TYPE = . (string)$xml-node['xsi:type'];
// Try using XML Parser
function tag_open($parser, $tag, $attributes) {
if (!empty($attributes)) { echo br / Tag: $tag Atrributes:
.print_r($attributes,true); }
}
$parser = xml_parser_create();
xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, false);
xml_set_element_handler($parser, tag_open, false);
xml_parse($parser, ltrim($xmlData));
Expected result:
Node XSI:TYPE = Test
Tag: root Atrributes: Array ( [xmlns:xsi] =
http://www.w3.org/2001/XMLSchema-instance )
Tag: node Atrributes: Array ( [xsi:type] = Test )
Actual result:
--
Node XSI:TYPE =
Tag: root Atrributes: Array ( [xmlns:xsi] =
http://www.w3.org/2001/XMLSchema-instance )
Tag: node Atrributes: Array ( [xsi:type] = Test )
--
Edit bug report at http://bugs.php.net/bug.php?id=53192edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53192r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53192r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53192r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53192r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53192r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53192r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53192r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53192r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53192r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53192r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53192r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53192r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53192r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53192r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53192r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53192r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53192r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53192r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53192r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53192r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53192r=mysqlcfg
[PHP-BUG] Bug #53194 [NEW]: path for dblib_stmt.c
From: Operating system: *nix win PHP version: 5.3.3 Package: MSSQL related Bug Type: Bug Bug description:path for dblib_stmt.c Description: I fix crash PHP_PDO_DBLIB when you try get MONEY fields from MSSQL database via FreeTDS data provider. For fixing this issue you must replace 174 line: val-len = spprintf(val-data, 0, %.4f, money_value); to val-len = spprintf(val-data, 0, %.4f, money_value); Please apply my path. -- Edit bug report at http://bugs.php.net/bug.php?id=53194edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53194r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53194r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53194r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53194r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53194r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53194r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53194r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53194r=needscript Try newer version: http://bugs.php.net/fix.php?id=53194r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53194r=support Expected behavior: http://bugs.php.net/fix.php?id=53194r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53194r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53194r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53194r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53194r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53194r=dst IIS Stability: http://bugs.php.net/fix.php?id=53194r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53194r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53194r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53194r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53194r=mysqlcfg
Bug #53194 [Opn-Bgs]: path for dblib_stmt.c
Edit report at http://bugs.php.net/bug.php?id=53194edit=1 ID: 53194 Updated by: fel...@php.net Reported by:mikhail dot v dot gavrilov at gmail dot com Summary:path for dblib_stmt.c -Status: Open +Status: Bogus Type: Bug Package:MSSQL related Operating System: *nix win PHP Version:5.3.3 Block user comment: N New Comment: This issue already has been fixed, see bug #52546. Previous Comments: [2010-10-28 17:55:54] mikhail dot v dot gavrilov at gmail dot com Description: I fix crash PHP_PDO_DBLIB when you try get MONEY fields from MSSQL database via FreeTDS data provider. For fixing this issue you must replace 174 line: val-len = spprintf(val-data, 0, %.4f, money_value); to val-len = spprintf(val-data, 0, %.4f, money_value); Please apply my path. -- Edit this bug report at http://bugs.php.net/bug.php?id=53194edit=1
Bug #53192 [Opn-Bgs]: SimpleXML ignores XSI:TYPE attributes
Edit report at http://bugs.php.net/bug.php?id=53192edit=1
ID: 53192
Updated by: rricha...@php.net
Reported by:jesse at eonstreet dot com
Summary:SimpleXML ignores XSI:TYPE attributes
-Status: Open
+Status: Bogus
Type: Bug
Package:SimpleXML related
Operating System: Windows 7 64bit
PHP Version:5.3.3
Block user comment: N
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
it works based on namespace scope so you need to tell it what namespace
is in
current scope for it to access the elements/attributes
Previous Comments:
[2010-10-28 16:01:01] jesse at eonstreet dot com
Description:
Hello,
It seems that SimpleXML removed all references to xsi:type in every
node.
XML Parser does show the xsi:type as an attribute.
The code below demonstrates this.
Test script:
---
$xmlData = 'root xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
node xsi:type=TestDATA/node/root';
// Try First with SimpleXml
$xml = simplexml_load_string($xmlData);
echo Node XSI:TYPE = . (string)$xml-node['xsi:type'];
// Try using XML Parser
function tag_open($parser, $tag, $attributes) {
if (!empty($attributes)) { echo br / Tag: $tag Atrributes:
.print_r($attributes,true); }
}
$parser = xml_parser_create();
xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, false);
xml_set_element_handler($parser, tag_open, false);
xml_parse($parser, ltrim($xmlData));
Expected result:
Node XSI:TYPE = Test
Tag: root Atrributes: Array ( [xmlns:xsi] =
http://www.w3.org/2001/XMLSchema-instance )
Tag: node Atrributes: Array ( [xsi:type] = Test )
Actual result:
--
Node XSI:TYPE =
Tag: root Atrributes: Array ( [xmlns:xsi] =
http://www.w3.org/2001/XMLSchema-instance )
Tag: node Atrributes: Array ( [xsi:type] = Test )
--
Edit this bug report at http://bugs.php.net/bug.php?id=53192edit=1
Bug #30471 [Com]: var_export: Nesting level too deep - recursive dependency?
Edit report at http://bugs.php.net/bug.php?id=30471edit=1 ID: 30471 Comment by: hendy at soluvas dot com Reported by:none at example dot com Summary:var_export: Nesting level too deep - recursive dependency? Status: Bogus Type: Bug Package:PHP options/info functions Operating System: Linux PHP Version:5.0.2 Assigned To:derick Block user comment: N New Comment: This bug is VALID! The following code works: var_dump($GLOBALS); Therefore the dumping algorithm is inconsistent. var_export() should just use the same algorithm as var_dump(). Previous Comments: [2010-06-27 05:55:26] jdickey at seven-sigma dot com Derick, I'd suggest that that expected behavior itself is a design flaw in the PHP interpreter. The solutions I can think of right off would be ugly, granted (special-case check for global-variable accessor to detect whether it's attempting to recurse as an effect of debug_backtrace() and, if so, throw an exception that can then be caught by d_bt); I find it really hard to believe that such a heavily- used software platform with such a large, competent company and community behind it can't come up with a better solution. Marking this bug as 'bogus' merely insults your developer customers and encourages them to go find a real language instead. [2004-11-15 20:19:24] der...@php.net There is no way to return a correct output in this case, so this is not a bug but expected behavior. [2004-10-18 17:33:05] none at example dot com Description: doing var_export( $GLOBALS, true ) there is an error like in older versions of php4: Nesting level too deep - recursive dependency? Of course it is easy to do a workaround, but maybe it would be nice to fix it. Theres a lot of discussion araound this bug in some communities for older php versions. Maybe it is me being in error or maybe this is just a feature and not a bug? In this case sorry for disturbing... Thanks a lot for all your work! Reproduce code: --- ?php $outText = var_export( $GLOBALS, true ); ? Expected result: I would expect to get var_export in $outText Actual result: -- array ( 'GLOBALS' = array ( 'GLOBALS' = array ( 'GLOBALS' = array ( Fatal error: Nesting level too deep - recursive dependency? -- Edit this bug report at http://bugs.php.net/bug.php?id=30471edit=1
[PHP-BUG] Bug #53195 [NEW]: __invoke fails when object is member of another object.
From:
Operating system: Windows
PHP version: 5.3.3
Package: Class/Object related
Bug Type: Bug
Bug description:__invoke fails when object is member of another object.
Description:
The magic invoke function fails to trigger if an object belongs to another
object.
Test script:
---
class A {
public function __invoke() {
echo 'hello from A ';
}
}
class B {
protected $a;
public function __invoke() {
echo 'hello from B ';
$this-a = new A();
$this-a();
}
}
$b = new B();
$b();
Expected result:
hello from B hello from A
Actual result:
--
hello from B
Fatal error: Call to undefined method B::a() in
C:\xampp\gazelle\tools\htdocs\testing.php on line 15
--
Edit bug report at http://bugs.php.net/bug.php?id=53195edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53195r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53195r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53195r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53195r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53195r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53195r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53195r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53195r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53195r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53195r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53195r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53195r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53195r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53195r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53195r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53195r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53195r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53195r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53195r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53195r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53195r=mysqlcfg
[PHP-BUG] Bug #53196 [NEW]: zend_API.h has an error in INIT_OVERLOADED_CLASS_ENTRY Macro
From: Operating system: Linux PHP version: 5.3.3 Package: Unknown/Other Function Bug Type: Bug Bug description:zend_API.h has an error in INIT_OVERLOADED_CLASS_ENTRY Macro Description: #define INIT_OVERLOADED_CLASS_ENTRY(class_container, class_name, functions, handle_fcall, handle_propget, handle_propset) \ INIT_OVERLOADED_CLASS_ENTRY_EX(class_container, class_name, sizeof(class_name)-1, functions, handle_fcall, handle_propget, handle_propset, NULL, NULL) leads to a segfault.. change it like #define INIT_OVERLOADED_CLASS_ENTRY(class_container, class_name, functions, handle_fcall, handle_propget, handle_propset) \ INIT_OVERLOADED_CLASS_ENTRY_EX(class_container, class_name, strlen(class_name)+1, functions, handle_fcall, handle_propget, handle_propset, NULL, NULL) -- Edit bug report at http://bugs.php.net/bug.php?id=53196edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53196r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53196r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53196r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53196r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53196r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53196r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53196r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53196r=needscript Try newer version: http://bugs.php.net/fix.php?id=53196r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53196r=support Expected behavior: http://bugs.php.net/fix.php?id=53196r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53196r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53196r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53196r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53196r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53196r=dst IIS Stability: http://bugs.php.net/fix.php?id=53196r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53196r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53196r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53196r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53196r=mysqlcfg
Bug #53196 [Opn-Bgs]: zend_API.h has an error in INIT_OVERLOADED_CLASS_ENTRY Macro
Edit report at http://bugs.php.net/bug.php?id=53196edit=1 ID: 53196 Updated by: fel...@php.net Reported by:sven dot assmann at lubico dot biz Summary:zend_API.h has an error in INIT_OVERLOADED_CLASS_ENTRY Macro -Status: Open +Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Linux PHP Version:5.3.3 Block user comment: N New Comment: This is not a bug, the macro is intended to use sizeof. You need to use the literal string in the macro, not a variable. Previous Comments: [2010-10-28 21:43:37] sven dot assmann at lubico dot biz Description: #define INIT_OVERLOADED_CLASS_ENTRY(class_container, class_name, functions, handle_fcall, handle_propget, handle_propset) \ INIT_OVERLOADED_CLASS_ENTRY_EX(class_container, class_name, sizeof(class_name)-1, functions, handle_fcall, handle_propget, handle_propset, NULL, NULL) leads to a segfault.. change it like #define INIT_OVERLOADED_CLASS_ENTRY(class_container, class_name, functions, handle_fcall, handle_propget, handle_propset) \ INIT_OVERLOADED_CLASS_ENTRY_EX(class_container, class_name, strlen(class_name)+1, functions, handle_fcall, handle_propget, handle_propset, NULL, NULL) -- Edit this bug report at http://bugs.php.net/bug.php?id=53196edit=1
Bug #53195 [Opn-Bgs]: __invoke fails when object is member of another object.
Edit report at http://bugs.php.net/bug.php?id=53195edit=1
ID: 53195
Updated by: fel...@php.net
Reported by:dmgx dot michael at gmail dot com
Summary:__invoke fails when object is member of another
object.
-Status: Open
+Status: Bogus
Type: Bug
-Package:Class/Object related
+Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.3.3
Block user comment: N
New Comment:
This is the expected behavior. And it is not exclusively related to
parent object... But all $this-closure.
See http://wiki.php.net/rfc/closures/object-extension
Previous Comments:
[2010-10-28 21:23:39] dmgx dot michael at gmail dot com
Description:
The magic invoke function fails to trigger if an object belongs to
another object.
Test script:
---
class A {
public function __invoke() {
echo 'hello from A ';
}
}
class B {
protected $a;
public function __invoke() {
echo 'hello from B ';
$this-a = new A();
$this-a();
}
}
$b = new B();
$b();
Expected result:
hello from B hello from A
Actual result:
--
hello from B
Fatal error: Call to undefined method B::a() in
C:\xampp\gazelle\tools\htdocs\testing.php on line 15
--
Edit this bug report at http://bugs.php.net/bug.php?id=53195edit=1
Bug #53196 [Bgs]: zend_API.h has an error in INIT_OVERLOADED_CLASS_ENTRY Macro
Edit report at http://bugs.php.net/bug.php?id=53196edit=1 ID: 53196 User updated by:sven dot assmann at lubico dot biz Reported by:sven dot assmann at lubico dot biz Summary:zend_API.h has an error in INIT_OVERLOADED_CLASS_ENTRY Macro Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Linux PHP Version:5.3.3 Block user comment: N New Comment: the macro is used by INIT_CLASS_ENTRY, if it is not a bug, what is the right way to initialize a class at runtime? I think the change on the macro will work for both ways compiletime and runtime.. Previous Comments: [2010-10-28 22:33:48] fel...@php.net This is not a bug, the macro is intended to use sizeof. You need to use the literal string in the macro, not a variable. [2010-10-28 21:43:37] sven dot assmann at lubico dot biz Description: #define INIT_OVERLOADED_CLASS_ENTRY(class_container, class_name, functions, handle_fcall, handle_propget, handle_propset) \ INIT_OVERLOADED_CLASS_ENTRY_EX(class_container, class_name, sizeof(class_name)-1, functions, handle_fcall, handle_propget, handle_propset, NULL, NULL) leads to a segfault.. change it like #define INIT_OVERLOADED_CLASS_ENTRY(class_container, class_name, functions, handle_fcall, handle_propget, handle_propset) \ INIT_OVERLOADED_CLASS_ENTRY_EX(class_container, class_name, strlen(class_name)+1, functions, handle_fcall, handle_propget, handle_propset, NULL, NULL) -- Edit this bug report at http://bugs.php.net/bug.php?id=53196edit=1
Bug #52510 [Com]: pg_query_params
Edit report at http://bugs.php.net/bug.php?id=52510edit=1
ID: 52510
Comment by: bob at garettgroup dot com
Reported by:phpdev dot ru at gmail dot com
Summary:pg_query_params
Status: Feedback
Type: Bug
Package:PostgreSQL related
Operating System: Mac OS X 10.6.4
PHP Version:5.3.3
Block user comment: N
New Comment:
My environment is:
Mac OS X 10.6.4
PHP 5.3.2
Apache 2.2.15
PostgreSQL 8.4.4
This is all confirm by phpinfo()
pg_connect() works as expected, however pg_query_params() is reported as
not found.
Previous Comments:
[2010-08-02 00:41:48] fel...@php.net
Probably the extension was compiled against an old libpq... because
pg_execute() and pg_query_params() requires PgSQL 7.4 or later.
[2010-08-02 00:33:09] phpdev dot ru at gmail dot com
Description:
Got a fatal error while trying to execute pg_query_params() or
pg_execute()
php 5.3.3 with libpq 8.4.4
Test script:
---
?php
$connection = pg_connect('dbname=test');
pg_query_params($connection, 'SELECT * FROM users WHERE id=$1',
array(1));
Expected result:
The function works fine
Actual result:
--
Fatal error: Call to undefined function pg_query_params()
--
Edit this bug report at http://bugs.php.net/bug.php?id=52510edit=1
