#48697 [Csd]: mb_internal_encoding() value gets reset by parse_str()
ID: 48697 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Closed Bug Type: mbstring related Operating System: PLD Linux PHP Version: 5.2.10 Assigned To: moriyoshi New Comment: nevermind, disregard my last post, seems commit is posted to bug, just not mailed to bug subscribers... Previous Comments: [2009-09-14 05:18:41] glen at delfi dot ee blah, why you never include scm commit in the bug? would be helpful instead have to dig myself [2009-09-14 04:12:54] moriyo...@php.net Changed the summary again as it turned out mb_parse_str() has nothing to do with this. [2009-09-14 04:11:48] moriyo...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-09-14 04:11:29] s...@php.net Automatic comment from SVN on behalf of moriyoshi Revision: http://svn.php.net/viewvc/?view=revision&revision=288301 Log: - Looks like bug #48697 has already been fixed in RC1. [2009-09-14 00:09:48] moriyo...@php.net Changed summary 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/48697 -- Edit this bug report at http://bugs.php.net/?id=48697&edit=1
#48697 [Csd]: mb_internal_encoding() value gets reset by parse_str()
ID: 48697 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Closed Bug Type: mbstring related Operating System: PLD Linux PHP Version: 5.2.10 Assigned To: moriyoshi New Comment: blah, why you never include scm commit in the bug? would be helpful instead have to dig myself Previous Comments: [2009-09-14 04:12:54] moriyo...@php.net Changed the summary again as it turned out mb_parse_str() has nothing to do with this. [2009-09-14 04:11:48] moriyo...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-09-14 04:11:29] s...@php.net Automatic comment from SVN on behalf of moriyoshi Revision: http://svn.php.net/viewvc/?view=revision&revision=288301 Log: - Looks like bug #48697 has already been fixed in RC1. [2009-09-14 00:09:48] moriyo...@php.net Changed summary [2009-07-09 07:21:49] ivan1986 at list dot ru ISO-8859-1 UTF-8 ISO-8859-1 must by ISO-8859-1 UTF-8 UTF-8 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/48697 -- Edit this bug report at http://bugs.php.net/?id=48697&edit=1
#48697 [Csd]: mb_internal_encoding() value gets reset by parse_str()
ID: 48697
Updated by: moriyo...@php.net
-Summary: mb_internal_encoding() value gets reset by parse_str()
or mb_parse_str()
Reported By: glen at delfi dot ee
Status: Closed
Bug Type: mbstring related
Operating System: PLD Linux
PHP Version: 5.2.10
Assigned To: moriyoshi
New Comment:
Changed the summary again as it turned out mb_parse_str() has nothing
to do with this.
Previous Comments:
[2009-09-14 04:11:48] moriyo...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2009-09-14 04:11:29] s...@php.net
Automatic comment from SVN on behalf of moriyoshi
Revision: http://svn.php.net/viewvc/?view=revision&revision=288301
Log: - Looks like bug #48697 has already been fixed in RC1.
[2009-09-14 00:09:48] moriyo...@php.net
Changed summary
[2009-07-09 07:21:49] ivan1986 at list dot ru
ISO-8859-1
UTF-8
ISO-8859-1
must by
ISO-8859-1
UTF-8
UTF-8
[2009-06-25 18:06:18] glen at delfi dot ee
Description:
setting mbstring internal encoding with mb_internal_encoding()
function gets reset at some point with 5.2.10, and mb_strtolower()
etc that are called without implicit charset will fail. (calling
mb_strtolower() with 2 arguments will succeed.
in other speak, such code fails:
echo mb_internal_encoding(); -> prints ISO-8859-1
mb_internal_encoding('UTF-8');
echo mb_internal_encoding(); -> prints UTF-8
... /// some code ///
echo mb_internal_encoding(); -> prints ISO-8859-1
if i set the internal encoding via php.ini (ini_set() is fine too),
then the problem does not occour. ie such code works ok:
echo mb_internal_encoding(); -> prints ISO-8859-1
ini_set("mbstring.internal_encoding", 'UTF-8');
echo mb_internal_encoding(); -> prints UTF-8
... /// that same code ///
echo mb_internal_encoding(); -> prints UTF-8
I have not yet able to create exact php code that is exact
reproducer, but the same php code, input data to php script, it
works with 5.2.9 and when reverting this commit:
http://www.mail-archive.com/php-cvs%40lists.php.net/msg40593.html
from brief looking i see that there is some inconsistency, that one
code sets the internal encoding from php.ini and the
mb_internal_encoding() function does not update php.ini setting.
--
Edit this bug report at http://bugs.php.net/?id=48697&edit=1
#48697 [Asn->Csd]: mb_internal_encoding() value gets reset by parse_str() or mb_parse_str()
ID: 48697
Updated by: moriyo...@php.net
Reported By: glen at delfi dot ee
-Status: Assigned
+Status: Closed
Bug Type: mbstring related
Operating System: PLD Linux
PHP Version: 5.2.10
Assigned To: moriyoshi
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-09-14 04:11:29] s...@php.net
Automatic comment from SVN on behalf of moriyoshi
Revision: http://svn.php.net/viewvc/?view=revision&revision=288301
Log: - Looks like bug #48697 has already been fixed in RC1.
[2009-09-14 00:09:48] moriyo...@php.net
Changed summary
[2009-07-09 07:21:49] ivan1986 at list dot ru
ISO-8859-1
UTF-8
ISO-8859-1
must by
ISO-8859-1
UTF-8
UTF-8
[2009-06-25 18:06:18] glen at delfi dot ee
Description:
setting mbstring internal encoding with mb_internal_encoding()
function gets reset at some point with 5.2.10, and mb_strtolower()
etc that are called without implicit charset will fail. (calling
mb_strtolower() with 2 arguments will succeed.
in other speak, such code fails:
echo mb_internal_encoding(); -> prints ISO-8859-1
mb_internal_encoding('UTF-8');
echo mb_internal_encoding(); -> prints UTF-8
... /// some code ///
echo mb_internal_encoding(); -> prints ISO-8859-1
if i set the internal encoding via php.ini (ini_set() is fine too),
then the problem does not occour. ie such code works ok:
echo mb_internal_encoding(); -> prints ISO-8859-1
ini_set("mbstring.internal_encoding", 'UTF-8');
echo mb_internal_encoding(); -> prints UTF-8
... /// that same code ///
echo mb_internal_encoding(); -> prints UTF-8
I have not yet able to create exact php code that is exact
reproducer, but the same php code, input data to php script, it
works with 5.2.9 and when reverting this commit:
http://www.mail-archive.com/php-cvs%40lists.php.net/msg40593.html
from brief looking i see that there is some inconsistency, that one
code sets the internal encoding from php.ini and the
mb_internal_encoding() function does not update php.ini setting.
--
Edit this bug report at http://bugs.php.net/?id=48697&edit=1
#49539 [Bgs]: {08} and {09} behave like {00}
ID: 49539
User updated by: info at daniel-marschall dot de
Reported By: info at daniel-marschall dot de
Status: Bogus
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5.2.0
New Comment:
I'm sorry. I didn't knew that a zero in front of a number makes
difference.
Previous Comments:
[2009-09-13 04:00:01] ras...@php.net
You have discovered octal numbers. There is no 08 and 09 in octal.
[2009-09-13 03:51:55] info at daniel-marschall dot de
(I mean "IIJJ", of course.)
[2009-09-13 03:50:26] info at daniel-marschall dot de
Description:
I believe I found an error in PHP 5.2.0-8+etch15 (cli)
The other values {00} to {07} are working as expected. Why doesn'T {08}
and {09} work? They should behave like {8} and {9} since 08 == 8 and 09
== 9.
Reproduce code:
---
Expected result:
Output: IIKK
Actual result:
--
Output: IAKA
--
Edit this bug report at http://bugs.php.net/?id=49539&edit=1
#49548 [NEW]: APC_UPLOAD_PROGRESS variable is cleared after one hour
From: farhana dot sathi at yahoo dot com Operating system: Windows XP pro PHP version: 5.2.10 PHP Bug Type: Unknown/Other Function Bug description: APC_UPLOAD_PROGRESS variable is cleared after one hour Description: I am using the APC to do an ajax style progress bar. Everything works fine for the first hour. But exactly after an hour the apc_fetch() return 0 ( more clearly APC_UPLOAD_PROGRESS is set to zero ) for the rest of the upload, seems that cache is cleared after one hour My APC settings in php.ini [APC] apc.enabled = 1 apc.rfc1867 = on apc.file_update_protection = 2 apc.enable_cli = 1 apc.max_file_size = 50M apc.shm_segments = 1 apc.shm_size = 512 apc.gc_ttl = 7200 apc.ttl = 7200 apc.user_ttl = 7200 apc.num_files_hint = 5000 apc.user_entries_hint = 5000 -- Edit bug report at http://bugs.php.net/?id=49548&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49548&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49548&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49548&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49548&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49548&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49548&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49548&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49548&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49548&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49548&r=support Expected behavior: http://bugs.php.net/fix.php?id=49548&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49548&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49548&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49548&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49548&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49548&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49548&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49548&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49548&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49548&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49548&r=mysqlcfg
#48697 [Asn]: mb_internal_encoding() value gets reset by parse_str() or mb_parse_str()
ID: 48697
Updated by: moriyo...@php.net
-Summary: mb_internal_encoding() value gets reset in process
Reported By: glen at delfi dot ee
Status: Assigned
Bug Type: mbstring related
Operating System: PLD Linux
PHP Version: 5.2.10
Assigned To: moriyoshi
New Comment:
Changed summary
Previous Comments:
[2009-07-09 07:21:49] ivan1986 at list dot ru
ISO-8859-1
UTF-8
ISO-8859-1
must by
ISO-8859-1
UTF-8
UTF-8
[2009-06-25 18:06:18] glen at delfi dot ee
Description:
setting mbstring internal encoding with mb_internal_encoding()
function gets reset at some point with 5.2.10, and mb_strtolower()
etc that are called without implicit charset will fail. (calling
mb_strtolower() with 2 arguments will succeed.
in other speak, such code fails:
echo mb_internal_encoding(); -> prints ISO-8859-1
mb_internal_encoding('UTF-8');
echo mb_internal_encoding(); -> prints UTF-8
... /// some code ///
echo mb_internal_encoding(); -> prints ISO-8859-1
if i set the internal encoding via php.ini (ini_set() is fine too),
then the problem does not occour. ie such code works ok:
echo mb_internal_encoding(); -> prints ISO-8859-1
ini_set("mbstring.internal_encoding", 'UTF-8');
echo mb_internal_encoding(); -> prints UTF-8
... /// that same code ///
echo mb_internal_encoding(); -> prints UTF-8
I have not yet able to create exact php code that is exact
reproducer, but the same php code, input data to php script, it
works with 5.2.9 and when reverting this commit:
http://www.mail-archive.com/php-cvs%40lists.php.net/msg40593.html
from brief looking i see that there is some inconsistency, that one
code sets the internal encoding from php.ini and the
mb_internal_encoding() function does not update php.ini setting.
--
Edit this bug report at http://bugs.php.net/?id=48697&edit=1
#44597 [NoF->Opn]: Postgres driver does not prepare booleans correctly
ID: 44597 User updated by: kenaniah at gmail dot com Reported By: kenaniah at gmail dot com -Status: No Feedback +Status: Open Bug Type: PDO related Operating System: Red Hat 4.1.1 PHP Version: 5.2.6 New Comment: This is still reproducible on 5.3.0 paired with PG 8.x Previous Comments: [2009-09-13 19:08:46] ant at specialops dot ath dot cx I can still reproduce this on PHP 5.3.0 and PostgreSQL 8.4.1. [2009-06-14 11:53:21] execut3 at gmail dot com The issue is still not fixed, I'm with PHP 5.2.6 on Ubuntu and postgresql 8.3. ERROR: invalid input syntax for type boolean: "" [2009-05-03 01:00:12] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-04-25 15:02:13] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-02-04 03:57:28] kenaniah at gmail dot com This issue seems like it would be a very easy fix and can be reproduced without fail, regardless of server environment or PHP version. A fix would be greatly appreciated 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/44597 -- Edit this bug report at http://bugs.php.net/?id=44597&edit=1
#49526 [Com]: C# style property get/set syntax
ID: 49526
Comment by: president at basnetworks dot net
Reported By: president at basnetworks dot net
Status: Open
Bug Type:Feature/Change Request
PHP Version: 6SVN-2009-09-11 (SVN)
New Comment:
For reference, the RFC for this feature request now exists at this
URL:
http://wiki.php.net/rfc/propertygetsetsyntax
Previous Comments:
[2009-09-13 04:24:08] president at basnetworks dot net
Hi Kalle,
Thanks for the information. I will follow your instructions and start
working on the RFC over the next week(s). Also, thanks for the link
about the Developer Summit, but it does not show the outcome of the
discussion, am I able to find that anywhere?
[2009-09-12 12:22:19] ka...@php.net
Hey
The best way to request this feature is to write an RFC in our wiki
at:
http://wiki.php.net/rfc/
Request an account at:
http://wiki.php.net/start?do=register
And then send an email to the webmaster list
(php-webmas...@lists.php.net) requesting write access to the rfc
namespace and repost this feature request as an RFC. When you are done,
start a new thread on internals (intern...@lists.php.net) explaining
your RFC.
As for reference, this idea was discussed at the last PDM in May, see:
http://wiki.php.net/summits/pdmnotesmay09#php_6 point #16
[2009-09-11 01:02:26] president at basnetworks dot net
Description:
I would like to request a C# style get/set syntax (called a property in
C#) for PHP. Basically, it looks and acts like a class member/variable
from outside the class, but it is actually a set of two methods. It can
be used to provide only read or write access to a class member, do pre
or post processing on a member, or be completely dynamic like a set of
class methods.
A property contains two methods between braces, named get and set. get
must always have a return statement, while set has a magic variable
"value" or "$value" which is the variable that was passed to the
property. Either method can be omitted to make the property read-only
or write-only.
The same effect can be achieved by creating a GetVar() and SetVar()
method to create a sudo-property "var", although it is by far much
clumsier and less intuitive.
I also realize the same effect received outside the class can be
achieved using the __get() and __set() methods, but these methods are
only really useful in a small instance of situations, like giving access
to an internal array as though each index is a property. These magic
methods are not at all useful for using on an individual property basis,
and it gets worse when inheritance is introduced.
The C# syntax is as follows:
class TimePeriod
{
private double seconds;
public double Hours
{
get { return seconds / 3600; }
set { seconds = value * 3600; }
}
}
The PHP syntax would be similar to the following:
class TimePeriod
{
private $seconds;
public property Hours
{
get { return $this->seconds / 3600; }
set { $this->seconds = $value * 3600; }
}
}
You would use it exactly the same as a public class member:
$time = new TimePeriod();
$time->Hours = 24;
echo $time->Hours;
As opposed to the alternative:
$time = new TimePeriod();
$time->SetHours(24);
echo $time->GetHours();
Additionally, the get and set methods can have separate visibilities
like in the following example where get is public and set is protected:
public property Name
{
get { return $this->name; }
protected set { $this->name = $value; }
}
There is another ticket that is similar but not the same thing here:
http://bugs.php.net/bug.php?id=34194
It suggests separate getter/setter methods, which in my opinion are
much less intuitive. I believe that following the C# format would help
to keep a standard format, and would be the least confusing.
The poster of that bug also fails to realize that separate visibility
levels can be achieved for properties using the C# syntax, as shown
above.
The C# documentation on properties is available here:
http://msdn.microsoft.com/en-us/library/x9fsa0sw%28VS.80%29.aspx
The C# documentation on Asymmetric Accessor Accessibility for
properties is available here:
http://msdn.microsoft.com/en-us/library/75e8y5dd%28VS.80%29.aspx
--
Edit this bug report at http://bugs.php.net/?id=49526&edit=1
#44597 [Com]: Postgres driver does not prepare booleans correctly
ID: 44597
Comment by: ant at specialops dot ath dot cx
Reported By: kenaniah at gmail dot com
Status: No Feedback
Bug Type: PDO related
Operating System: Red Hat 4.1.1
PHP Version: 5.2.6
New Comment:
I can still reproduce this on PHP 5.3.0 and PostgreSQL 8.4.1.
Previous Comments:
[2009-06-14 11:53:21] execut3 at gmail dot com
The issue is still not fixed, I'm with PHP 5.2.6 on Ubuntu and
postgresql 8.3.
ERROR: invalid input syntax for type boolean: ""
[2009-05-03 01:00:12] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-04-25 15:02:13] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-02-04 03:57:28] kenaniah at gmail dot com
This issue seems like it would be a very easy fix and can be reproduced
without fail, regardless of server environment or PHP version.
A fix would be greatly appreciated
[2008-10-07 19:23:48] dac514 at hotmail dot com
This is happening to me too, OS X and CentOS, PHP 5.2.6
I am converting a web application from MySql to PostgreSQL and i've
run into a roadbloack that is forcing me to find every single boolean
query and manually binding it instead of benefiting from execute()
$input_parameters. PITA! I discovered the explanation to this "bug"
here:
http://ca.php.net/manual/en/pdostatement.execute.php#84990
As of 5.2.6 you still can't use PDOStatement->execute()
$input_parameters to pass a boolean to PostgreSQL. To do that, you'll
have to call bindParam() with explicit types for *each* parameter in
the query.
Pseudo example, where col5 is of type boolean (i.e. tinyint(1) in
MySQL)
$q = 'INSERT INTO table (col1, col2, col3, col4, col5, col6) VALUES (?
, ?, ?, ?, ?, ?)';
$v = array('foo1', 'foo2', 'foo3', foo4', false, 'foo6');
$st = $db->prepare($q);
$st->execute($v);
PostgreSQL complains and the script dies. Leaving me in the cold and I
have to rewrite the code, which becomes excessively painful when the
queries are dynamically generated. PostgreSQL workaround, boo!
$q = 'INSERT INTO table (col1, col2, col3, col4, col5, col6) VALUES (?
, ?, ?, ?, ?, ?)';
$v = array('foo1', 'foo2', 'foo3', foo4', false, 'foo6');
$st = $db->prepare($q);
$st->bindParam(1, $v[0]], PDO::PARAM_STR);
$st->bindParam(2, $v[1]], PDO::PARAM_STR);
$st->bindParam(3, $v[2]], PDO::PARAM_STR);
$st->bindParam(4, $v[3]], PDO::PARAM_STR);
$st->bindParam(5, $v[4]], PDO::PARAM_BOOL);
$st->bindParam(6, $v[5]], PDO::PARAM_STR);
$st->execute();
Can we get a fix for this soon?
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/44597
--
Edit this bug report at http://bugs.php.net/?id=44597&edit=1
#49546 [NEW]: DFSDFD
From: gezine at hotmail dot com
Operating system: Windows
PHP version: 5.3.0
PHP Bug Type: IIS related
Bug description: DFSDFD
Description:
Locally on my computer my connection to the database works fine but the
moment I upload my file to the web server, and submit a form I receive the
error.
Webserver Information
---
Operating System: Windows
PHP Version: PHP 5.x IIS
Version: IIS 7.0
code tried but no luck
--
http://us3.php.net/manual/en/function.odbc-connect.php
Reproduce code:
---
function connect_to_database($dsn, $user, $password)
{
//create a connection to the database
$conn = odbc_connect($dsn, $user, password,SQL_CUR_USE_DRIVER);
//if the connection failed display the appropriate message
if(!$conn)
{
output_error();
die();
}//end if(_);
else
{
//return connection has been established.
return $conn;
}//end else
}//end connect_to_database(_);
Expected result:
I expected a successful return since every thing on the webserver(Godaddy)
is setup correctly according to their test.
Actual result:
--
"Warning: odbc_connect() [function.odbc-connect]: SQL error:
[Microsoft][ODBC Driver Manager] Data source name not found and no default
driver specified, SQL state IM002 in SQLConnect in "
--
Edit bug report at http://bugs.php.net/?id=49546&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49546&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49546&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49546&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49546&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49546&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49546&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49546&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49546&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49546&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49546&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49546&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49546&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49546&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49546&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49546&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49546&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49546&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49546&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49546&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49546&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49546&r=mysqlcfg
#49545 [NEW]: PHP, IIS, MYSQL
From: gezine at hotmail dot com
Operating system: Windows
PHP version: 5.3.0
PHP Bug Type: ODBC related
Bug description: PHP, IIS, MYSQL
Description:
Locally on my computer my connection to the database works fine but the
moment I upload my file to the web server, and submit a form I receive the
error.
Webserver Information
---
Operating System: Windows
PHP Version: PHP 5.x IIS
Version: IIS 7.0
code tried but no luck
--
http://us3.php.net/manual/en/function.odbc-connect.php
Reproduce code:
---
function connect_to_database($dsn, $user, $password)
{
//create a connection to the database
$conn = odbc_connect($dsn, $user, password,SQL_CUR_USE_DRIVER);
//if the connection failed display the appropriate message
if(!$conn)
{
output_error();
die();
}//end if(_);
else
{
//return connection has been established.
return $conn;
}//end else
}//end connect_to_database(_);
Expected result:
I expected a successful return since every thing on the webserver(Godaddy)
is setup correctly according to their test.
Actual result:
--
"Warning: odbc_connect() [function.odbc-connect]: SQL error:
[Microsoft][ODBC Driver Manager] Data source name not found and no default
driver specified, SQL state IM002 in SQLConnect in "
--
Edit bug report at http://bugs.php.net/?id=49545&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49545&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49545&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49545&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49545&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49545&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49545&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49545&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49545&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49545&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49545&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49545&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49545&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49545&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49545&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49545&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49545&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49545&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49545&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49545&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49545&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49545&r=mysqlcfg
#49472 [Ver]: Constants defined in Interfaces can be overridden
ID: 49472 Updated by: j...@php.net Reported By: phil at mossyvale dot co dot uk Status: Verified Bug Type: Class/Object related Operating System: * PHP Version: 5.*, 6 New Comment: show(); ?> Previous Comments: [2009-09-05 10:08:19] phil at mossyvale dot co dot uk Description: If an interface defines a constant and is then implemented by a class which is then extended with a further class and both classes implement the interface, the second class may override the interface constant without a fatal error. Also present in 5.2.10 on FreeBSD 7.2 Reproduce code: --- --- >From manual page: language.oop5.interfaces --- http://codepad.org/vStYX1Kz Expected result: Fatal error: Cannot inherit previously-inherited constant c from interface ia ... on line 18 Actual result: -- Program outputs "OceanSea" which indicates that the interface constant is still available but the class constant with the same name overrides it. -- Edit this bug report at http://bugs.php.net/?id=49472&edit=1
#49544 [NEW]: No international characters in ldap_add
From: lucas dot bru at terra dot com dot br Operating system: Ubuntu 9.10 PHP version: 5.3.0 PHP Bug Type: LDAP related Bug description: No international characters in ldap_add Description: Hi. the function ldap_add dont accpet if the array data haves international characters like as "josé". See the code below. Reproduce code: --- $info["uid"] = $_POST['uid']; $info["userPassword"] = $_POST['userPassword']; $info["cn"]= $_POST['cn']; $info["sn"]= $_POST['sn']; $info["mail"] = $_POST['mail']; $info["objectClass"] = "inetOrgPerson"; $dn= "uid=" . $_POST['uid'] . ", dc=thevip, dc=com,dc=br"; $result = ldap_add($conn, $dn, $info); Expected result: its works, but not if any data have latin characters like as "josé" "maça" and all others Actual result: -- Warning: ldap_add() [function.ldap-add]: Add: Invalid syntax in /var/www. -- Edit bug report at http://bugs.php.net/?id=49544&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49544&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49544&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49544&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49544&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49544&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49544&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49544&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49544&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49544&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49544&r=support Expected behavior: http://bugs.php.net/fix.php?id=49544&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49544&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49544&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49544&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49544&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49544&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49544&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49544&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49544&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49544&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49544&r=mysqlcfg
#49543 [NEW]: closures cannot import/inherit $this
From: mjs at beebo dot org
Operating system: Ubuntu
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: closures cannot import/inherit $this
Description:
Attempting to import/inherit $this produces the compile-time error
"Cannot use $this as lexical variable."
Note that the workaround of assigning $this to the temporary variable
$tmp, and inheriting $tmp instead does work, so there appears to be no
limitation in the engine:
class Foo {
public function bar() {
$tmp = $this;
return function() use ($tmp) {
echo "in closure\n";
}
}
}
See also http://wiki.php.net/rfc/closures/removal-of-this. (It
appears that $this was once automatically imported into the closure's
scope, but that this turned out to be a bad idea. This bug report
concerns what happens when $this is explicitly imported, however.)
Reproduce code:
---
http://bugs.php.net/?id=49543&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49543&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49543&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49543&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49543&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49543&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49543&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49543&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49543&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49543&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49543&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49543&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49543&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49543&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49543&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49543&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49543&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49543&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49543&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49543&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49543&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49543&r=mysqlcfg
#49542 [NEW]: __callStatic() only invoked if instance method does not exist
From: mjs at beebo dot org
Operating system: Ubuntu
PHP version: 5.3.0
PHP Bug Type: Class/Object related
Bug description: __callStatic() only invoked if instance method does not exist
Description:
A static call to Foo::bar() does not invoke __callStatic() if an
instance method bar() exists.
One reason you might want this is to convert static calls to Foo::bar()
to the equivalent operation on a singleton:
public static function __callStatic($name, $args) {
$obj = self::getInstance();
return call_user_func_array(array($obj, $name), $args);
}
In the sample code below, __callStatic() is not invoked even though the
caller has deliberately initiated a static call.
Reproduce code:
---
http://bugs.php.net/?id=49542&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49542&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49542&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49542&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49542&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49542&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49542&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49542&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49542&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49542&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49542&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49542&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49542&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49542&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49542&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49542&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49542&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49542&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49542&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49542&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49542&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49542&r=mysqlcfg
#49541 [Bgs]: max_execution_time = 3600, still stops at 60
ID: 49541 User updated by: no_email at no_spam dot com Reported By: no_email at no_spam dot com Status: Bogus Bug Type: PHP options/info functions Operating System: Windows 7 64-bit PHP Version: 5.3.0 New Comment: SAPI: Apache 2.0 Handler. I'll give you my email if you hide it from public. You obfuscation is too weak and you know it. PS. Is there some problem with my attitude, or yours? I feel like I'm sorry to spent my time leaving this report, which is a real reproducible issue for me. "No email, no way to receive emails, no bug." Is that an answer you would give to a client? Should I kirjoittaa suomeksi to get some respect? If it is not a bug, how can I get past 60 seconds limit? Please tell me, it's not in documentation. Previous Comments: [2009-09-13 13:45:56] j...@php.net No email, no way to receive emails, no bug. [2009-09-13 13:35:50] ka...@php.net What SAPI are you using? IIS7 with FastCGI? [2009-09-13 12:33:55] no_email at no_spam dot com Description: Correct php.ini is loaded with max_execution_time = 3600 and using phpinfo() both local and master values are 3600, no additional ini files are parsed. Still with 5.3. script execution stops always at 60 secs. -- Edit this bug report at http://bugs.php.net/?id=49541&edit=1
#49419 [Com]: ssl:// wrapper - cannot verify VeriSign certificate chain
ID: 49419 Comment by: ryan+phpbugs at sleevi dot com Reported By: Jacek at jacekk dot info Status: Open Bug Type: OpenSSL related Operating System: Ubuntu PHP Version: 5.3.0 New Comment: As mentioned previously, the PayPal URL returns HTTP 500. This is not an SSL error, it is an error in the URL being requested. However, the fact that you get that error indicates OpenSSL is working correctly. Verifying a certificate necessarily involves verifying its' entire chain. Begin with a simple chain where A issues B issues C. C is the certificate the web server is using. To make sure that C is authorized, you must consult C to see if it's issuer has placed any restrictions/constraints on it. However, restrictions are inherited properties, so you must *ALSO* check both B and A to make sure no restrictions are placed. What C is allowed to do is the combined, least permissive set of A, B, and C. This is spelled out in the various PKI/PKIX RFCs. OpenSSL, as best I can tell, does not integrate alternative certificate path building algorithms when multiple paths may exist. That was your problem with Verisign, the server supplies one chain, while you were expecting/trusting a different chain path. This can be implemented with the OpenSSL verify callback, but not directly in PHP. At that point, it becomes more of a feature request, then a bug. In the matter of trusting intermediates, OpenSSL 0.9.8 makes specific mention in several places throughout x509_vfy.c (the code which contains the verification routines), that it only attempts to complete the chain at the last untrusted certificate. Per the TLS specification, a server sends its cert, and additionally any supplementary/intermediate certificates it believes clients' will need to build a chain. To visualize, think of a chain that goes A B C D E F, where F is the server certificate and A is the root certificate. When connecting via TLS, the server may supply: F F E F E D etc. In OpenSSL, and therefore in PHP, it expects to try to verify the last certificate (and the remaining chain). If you connect to a server that only supplies F, then you need to have E-A in your certificate store. If a server supplies F E D, then you need to have C-A in your certificate store. And if a server supplies F-A (such as Verisign does), then you only need to have A in your store. This is a very simple model for path building that OpenSSL supports in-code (though it provides the means to support other methods via the necessary callbacks, I believe). RFC 4158 provides some of the complexities involved with path building and the various structures that may be represented. All of that to say that, in today's world and with today's code, yes, you are best supplying all of the intermediates that you trust, in addition to the root certificates, as the servers you are connecting to may not all be configured to send them, and trust will fail otherwise. Further, in today's code, simply trusting the intermediate is often not enough to successfully pass verification. Previous Comments: [2009-09-04 17:21:59] Jacek at jacekk dot info > what version have you linked against with your PHP? I've tested it on PHP linked against OpenSSL 0.9.8g (Ubuntu LTS) and 0.9.8k (Gentoo) I understand how certificate checking works and I've provided wrong chain - my bad, however with the file you linked PHP still shows warnings form the first message. One more question: must OpenSSL check whole path, if one of intermediate certificates exists in cafile? [2009-09-04 06:59:44] ryan+phpbugs at sleevi dot com I was unable to reproduce the "good" OpenSSL output that you described, using OpenSSL FIPS 1.2. For documentation sake (and because everything I'm about to explain is relative to that, which is equivalent to 0.9.8f code more or less), what version have you linked against with your PHP? Running openssl s_client -connect www.verisign.com:443 -CAfile chain.pem I get CONNECTED(0003) depth=3 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/2.5.4.15=V1.0, Clause 5.(b)/serialNumber=2497886/C=US/postalCode=94043/ST=California/L=Mountain View/streetAddress=487 East Middlefield Road/O=VeriSign, Inc./OU=Production Security Services/CN=www.verisign.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/
#49541 [Fbk->Bgs]: max_execution_time = 3600, still stops at 60
ID: 49541 Updated by: j...@php.net Reported By: no_email at no_spam dot com -Status: Feedback +Status: Bogus Bug Type: PHP options/info functions Operating System: Windows 7 64-bit PHP Version: 5.3.0 New Comment: No email, no way to receive emails, no bug. Previous Comments: [2009-09-13 13:35:50] ka...@php.net What SAPI are you using? IIS7 with FastCGI? [2009-09-13 12:33:55] no_email at no_spam dot com Description: Correct php.ini is loaded with max_execution_time = 3600 and using phpinfo() both local and master values are 3600, no additional ini files are parsed. Still with 5.3. script execution stops always at 60 secs. -- Edit this bug report at http://bugs.php.net/?id=49541&edit=1
#49541 [Opn->Fbk]: max_execution_time = 3600, still stops at 60
ID: 49541 Updated by: j...@php.net Reported By: no_email at no_spam dot com -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Windows 7 64-bit PHP Version: 5.3.0 Previous Comments: [2009-09-13 13:35:50] ka...@php.net What SAPI are you using? IIS7 with FastCGI? [2009-09-13 12:35:44] no_email at no_spam dot com removed email why do you display it in public? [2009-09-13 12:33:55] no_email at no_spam dot com Description: Correct php.ini is loaded with max_execution_time = 3600 and using phpinfo() both local and master values are 3600, no additional ini files are parsed. Still with 5.3. script execution stops always at 60 secs. -- Edit this bug report at http://bugs.php.net/?id=49541&edit=1
#49541 [Opn]: max_execution_time = 3600, still stops at 60
ID: 49541 Updated by: ka...@php.net Reported By: no_email at no_spam dot com Status: Open Bug Type: PHP options/info functions Operating System: Windows 7 64-bit PHP Version: 5.3.0 New Comment: What SAPI are you using? IIS7 with FastCGI? Previous Comments: [2009-09-13 12:35:44] no_email at no_spam dot com removed email why do you display it in public? [2009-09-13 12:33:55] no_email at no_spam dot com Description: Correct php.ini is loaded with max_execution_time = 3600 and using phpinfo() both local and master values are 3600, no additional ini files are parsed. Still with 5.3. script execution stops always at 60 secs. -- Edit this bug report at http://bugs.php.net/?id=49541&edit=1
#49541 [Opn]: max_execution_time = 3600, still stops at 60
ID: 49541 User updated by: no_email at no_spam dot com -Reported By: pekka dot saarinen at yahoo dot com +Reported By: no_email at no_spam dot com Status: Open Bug Type: PHP options/info functions Operating System: Windows 7 64-bit PHP Version: 5.3.0 New Comment: removed email why do you display it in public? Previous Comments: [2009-09-13 12:33:55] no_email at no_spam dot com Description: Correct php.ini is loaded with max_execution_time = 3600 and using phpinfo() both local and master values are 3600, no additional ini files are parsed. Still with 5.3. script execution stops always at 60 secs. -- Edit this bug report at http://bugs.php.net/?id=49541&edit=1
#49541 [NEW]: max_execution_time = 3600, still stops at 60
From: pekka dot saarinen at yahoo dot com Operating system: Windows 7 64-bit PHP version: 5.3.0 PHP Bug Type: PHP options/info functions Bug description: max_execution_time = 3600, still stops at 60 Description: Correct php.ini is loaded with max_execution_time = 3600 and using phpinfo() both local and master values are 3600, no additional ini files are parsed. Still with 5.3. script execution stops always at 60 secs. -- Edit bug report at http://bugs.php.net/?id=49541&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49541&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49541&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49541&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49541&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49541&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49541&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49541&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49541&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49541&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49541&r=support Expected behavior: http://bugs.php.net/fix.php?id=49541&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49541&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49541&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49541&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49541&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49541&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49541&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49541&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49541&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49541&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49541&r=mysqlcfg
