#13825 [Com]: sort functions
ID: 13825
Comment by: jo at durchholz dot org
Reported By: lee at mediawaveonline dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: linux, windows
PHP Version: 4.0.6
New Comment:
I agree that there should be functions that return a sorted array
instead of sorting in-place. Given the way that PHP handles variables,
this should be no more than moderately inefficient.
I also find the multitude of sort functions confusing. I always have to
look them up. I'd suggest a sort function like this:
sorted ($array, $flags, $compare_fn = NULL, $compare_flags = 0)
where $flags may be combined from one of each of the following lines
(first flag is the default):
SORT_REGULAR/SORT_NUMERIC/SORT_STRING
These flags define how the values to be sorted (whether it's keys
or values) are to be transformed before comparing.
SORT_NUMERIC converts the values to be sorted to numbers.
SORT_STRING converts them to strings.
SORT_VALUES/SORT_KEYS/SORT_VALUES_KEYS/SORT_KEYS_VALUES
SORT_KEYS has the effect of ksort.
SORT_VALUES_KEYS sorts by values, resorting to keys if values are
equal.
SORT_KEYS_VALUES sorts by key, then value. This can make sense
with SORT_NUMERIC or SORT_STRING if two keys get mapped to the
same value.
SORT_REINDEX/SORT_KEEP_KEYS
Whether to reindex the result array numerically or keep the
key-value associations. (Numeric keys probably need to be
reindexed always, but I don't know all ramifications here.)
SORT_KEEP_KEYS gives the effect of asort.
SORT_REGULAR/SORT_REVERSE
SORT_REVERSE has the effect of rsort.
$compare_fn ($a, $b, $flags) will get the values to be compared in $a
and $b, and sorted()s $compare_flags in $flags.
For SORT_VALUES, $a and $b will be values from $array.
For SORT_KEYS, $a and $b will be keys from $array.
For SORT_VALUES_KEYS, $a and $b will be arrays ($value, $key) from a
$value=$key pair in $array.
For SORT_KEYS_VALUES, $a and $b will be arrays ($key, $value) from a
$value=$key pair in $array.
For $compare_flags, the only flag that could be predefined is
SORT_LOCALE.
If no $compare_fn is given, the equivalent of this PHP code is
executed:
?php
if (is_array ($a)) {
$result = _compare ($a [0], $b [0]);
if ($result == 0) {
return _compare ($a [1], $b [1]);
} else {
return $result;
}
} else {
return _compare ($a, $b);
}
?
where _compare is defined to return -1, 0, or +1 depending on how its
two parameters compare.
Hope this is useful :-)
Previous Comments:
[2001-10-25 11:38:43] lee at mediawaveonline dot com
$test[0] = 0;
$test[1] = 1;
$test[2] = 2;
asort($test);
I hate this, a function should never modify a variable, it should
return the new modified variable. they syntax should be
$test = asort($test);
there are good reasons or this. I hate needing a variable sorted for
one command and having to make a temp var just todo that.
$tmp = $test;
asort($tmp);
foreach( $tmp as $pos = $val )
where it could be.
foreach( asort($test) as $pos = $val )
saves time and ledgibility. I understand its not easy to change the
syntax now. if you wanted to make some work or yourself you could make
this a php.ini option. if you want something simpler on your end, just
make a new set of functions, thats what Ive done.
function my_asort($array)
{
asort($array);
return $array);
}
even if you dont want to ever include this into base php, at least make
asort return the newly modified variable.
$tmp = $test;
foreach( asort($tmp) as $pos = $val )
Chris Lee
[EMAIL PROTECTED]
--
Edit this bug report at http://bugs.php.net/?id=13825edit=1
#40888 [NEW]: Sorts should be stable
From: jo at durchholz dot org Operating system: Irrelevant PHP version: 4.4.5 PHP Bug Type: Feature/Change Request Bug description: Sorts should be stable Description: The manual says this on sorting: If two members compare as equal, their order in the sorted array is undefined. Up to PHP 4.0.6 the user defined functions would keep the original order for those elements, but with the new sort algorithm introduced with 4.1.0 this is no longer the case as there is no solution to do so in an efficient way. Bug #18299 requests that the old (stable) sort behavior be restored. This is denied on the grounds that there is no efficient implementation for that. Now it *is* possible to stabilize any sort algorithm, by comparing key positions if values compare equal. Um, well, I can imagine that it's inefficient to determine the position of a key. In that case, I'd propose to introduce a SORT_STABLE flag and have the engine create a key=position array when sorting with SORT_STABLE. That would still be more efficient than trying to stabilize the sort at the PHP level. There, I'd have to do the following to get a stable sort: * Make a copy of the array, wrapping each value in an array ($position, $value) * Sort with a user-defined function. Have that function compare $values, and if these compare equal, compare $positions. * Unwrap the $values from the resulting sorted array. In effect, this means the engine will have to construct and garbage collect an array for each array element, so this is horribly inefficient compared to any in-engine solution... -- Edit bug report at http://bugs.php.net/?id=40888edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40888r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40888r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40888r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40888r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40888r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40888r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40888r=needscript Try newer version:http://bugs.php.net/fix.php?id=40888r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40888r=support Expected behavior:http://bugs.php.net/fix.php?id=40888r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40888r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40888r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40888r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40888r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40888r=dst IIS Stability:http://bugs.php.net/fix.php?id=40888r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40888r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40888r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40888r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40888r=mysqlcfg
#40889 [NEW]: Coll-assignElem(n,str) and Coll-append(str) causes memory leak
From: uno at venus dot dti dot ne dot jp Operating system: Linux PHP version: 4.4.6 PHP Bug Type: OCI8 related Bug description: Coll-assignElem(n,str) and Coll-append(str) causes memory leak Description: I found that coll-append(string); or coll-assignElem(n,string); cause memory leak. You need to free OCIAssignText()'ed strings with OCIStringResize() in oci8.c (PHP 4.4.6) and oci8_collection.c (PHP 5.2.1, PECL/oci8-1.2.3) because OCICollAppend() and OCICollAssignElem() perform deep-copy of element value. see: http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci18map001.htm#i448982 http://download-east.oracle.com/docs/cd/A58617_01/server.804/a58234/orl_func.htm#426353 Reproduce code: --- $collStr = ocinewcollection( ... ); $collStr-append(string); /* memory leak */ $collStr-assignElem(0,string);/* memory leak */ $collNum = ocinewcollection( ... ); $collNum-append(1234); /* no memory leak */ $collNum-assignElem(0, 5678); /* no memory leak */ $collDate = ocinewcollection( ... ); $collDate-append(2007-01-01); /* no memory leak */ $collDate-assignElem(0, 2007-02-02); /* no memory leak */ Expected result: no memory leak Actual result: -- memory leak -- Edit bug report at http://bugs.php.net/?id=40889edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40889r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40889r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40889r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40889r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40889r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40889r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40889r=needscript Try newer version:http://bugs.php.net/fix.php?id=40889r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40889r=support Expected behavior:http://bugs.php.net/fix.php?id=40889r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40889r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40889r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40889r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40889r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40889r=dst IIS Stability:http://bugs.php.net/fix.php?id=40889r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40889r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40889r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40889r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40889r=mysqlcfg
#40890 [NEW]: long set_magic_quotes_gpc(int new_setting)
From: bothie at gmx dot de Operating system: any PHP version: 5.2.1 PHP Bug Type: Feature/Change Request Bug description: long set_magic_quotes_gpc(int new_setting) Description: Add functions like long set_magic_quotes_gpc(int new_setting) Having security in mind, many web application (WA) programmers expect magic_quotes_gpc to be set (or to be not set). It's possible to write WAs which can tolerate both settings but the most easiest ist to have just magic_quotes_gpc being set which is the default of course. But some sites have magic_quotes_gpc not set. So mixing WAs expecting magic_quotes_gpc to be set and WAs expecting magic_quotes_gpc not to be set is impossible. A new introduced function set_magic_quotes_gpc would change that as any program can enforce that setting in that way which it self expects it for it's own runtime. (This feature request should be seen a little bit more general, any other value which could be set in php.ini should get it's set_ counterpart as well except for some exceptions like disable_functions, for which a set- counterpart may not be so wise - or at least a set_disable_function should only be able to ADD additional functions to the set of disabled functions, not to REMOVE any of them specified in php.ini). (I've just seen the ini_set-function and am very disappointed about it NOT supporting a change to magic_quotes_gpc!) -- Edit bug report at http://bugs.php.net/?id=40890edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40890r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40890r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40890r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40890r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40890r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40890r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40890r=needscript Try newer version:http://bugs.php.net/fix.php?id=40890r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40890r=support Expected behavior:http://bugs.php.net/fix.php?id=40890r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40890r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40890r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40890r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40890r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40890r=dst IIS Stability:http://bugs.php.net/fix.php?id=40890r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40890r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40890r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40890r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40890r=mysqlcfg
#40882 [Opn-Bgs]: �rray_fill doesn't support negative start index
ID: 40882 Updated by: [EMAIL PROTECTED] Reported By: guile_spam at laposte dot net -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Linux 2.6.12-12mdk #1 F PHP Version: 5.2.1 New Comment: I guess could have the answer in the bug 24159... Right, so this is expected. Previous Comments: [2007-03-21 16:00:30] guile_spam at laposte dot net Description: the function array_fill doesn't support correctly a negative number as first parameter. If start_index is negative, then it starts with the correct value, but the next key value is always 0. I guess could have the answer in the bug 24159... Maybe the documentation have to be updated, or (I hope it will be this solution) the function array_fill have to fixed :-P Thx for all! Reproduce code: --- ?php print_r(array_fill(-3,5,0)); ? Expected result: Array ( [-3] = 0 [-2] = 0 [-1] = 0 [0] = 0 [1] = 0 ) Actual result: -- Array ( [-3] = 0 [0] = 0 [1] = 0 [2] = 0 [3] = 0 ) -- Edit this bug report at http://bugs.php.net/?id=40882edit=1
#40889 [Opn-Fbk]: Coll-assignElem(n,str) and Coll-append(str) causes memory leak
ID: 40889 Updated by: [EMAIL PROTECTED] Reported By: uno at venus dot dti dot ne dot jp -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: Linux PHP Version: 4.4.6 New Comment: Are you using OCI8 from PECL? If yes, which version? Previous Comments: [2007-03-22 09:01:51] uno at venus dot dti dot ne dot jp Description: I found that coll-append(string); or coll-assignElem(n,string); cause memory leak. You need to free OCIAssignText()'ed strings with OCIStringResize() in oci8.c (PHP 4.4.6) and oci8_collection.c (PHP 5.2.1, PECL/oci8-1.2.3) because OCICollAppend() and OCICollAssignElem() perform deep-copy of element value. see: http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci18map001.htm#i448982 http://download-east.oracle.com/docs/cd/A58617_01/server.804/a58234/orl_func.htm#426353 Reproduce code: --- $collStr = ocinewcollection( ... ); $collStr-append(string); /* memory leak */ $collStr-assignElem(0,string);/* memory leak */ $collNum = ocinewcollection( ... ); $collNum-append(1234); /* no memory leak */ $collNum-assignElem(0, 5678); /* no memory leak */ $collDate = ocinewcollection( ... ); $collDate-append(2007-01-01); /* no memory leak */ $collDate-assignElem(0, 2007-02-02); /* no memory leak */ Expected result: no memory leak Actual result: -- memory leak -- Edit this bug report at http://bugs.php.net/?id=40889edit=1
#40887 [Opn-Fbk]: ob_start(ob_iconv_handler) can't do nesting!
ID: 40887 Updated by: [EMAIL PROTECTED] Reported By: haha_lover at 163 dot com -Status: Open +Status: Feedback Bug Type: Output Control Operating System: winxp / linux-2.6.11-1.1369_FC4 PHP Version: 5.2.1 New Comment: PS: bugs.php.net submitting has done htmlentities() to the Chinese words in my program. Upload it somewhere and put the URL here. Previous Comments: [2007-03-22 04:16:23] haha_lover at 163 dot com PS: bugs.php.net submitting has done htmlentities() to the Chinese words in my program. If you use this encoded program code , the ob_start(ob_iconv_handler) can work in nestings. But after all, I can't write my templates in this htmlentities style. [2007-03-22 04:03:37] haha_lover at 163 dot com Description: ob_start() can nest as the description in php manual: Output buffers are stackable, that is, you may call ob_start() while another ob_start() is active. But ob_start(ob_iconv_handler) CAN'T. Reproduce code: --- ?php /** * Test: Can I nest ob_start(ob_iconv_handler) ? * * Result#65306;I can't. It stop at internal nesting when meet a Chinese word. */ iconv_set_encoding(internal_encoding, GB2312); iconv_set_encoding(output_encoding, UTF-8); ob_start(ob_iconv_handler); ? p ALTER DATABASE#29992;#20110;#26356;#25913;#25968;#25454;#24211;#30340;#20840;#23616;#29305;#24615;#12290; /p ? ob_start(ob_iconv_handler); ? p ALTER DATABASE#29992;#20110;#26356;#25913;#25968;#25454;#24211;#30340;#20840;#23616;#29305;#24615;#12290; /p ? ob_end_flush(); ob_end_flush(); ? Expected result: ALTER DATABASE#29992;#20110;#26356;#25913;#25968;#25454;#24211;#30340;#20840;#23616;#29305;#24615;#12290; ALTER DATABASE#29992;#20110;#26356;#25913;#25968;#25454;#24211;#30340;#20840;#23616;#29305;#24615;#12290; Actual result: -- ALTER DATABASE#29992;#20110;#26356;#25913;#25968;#25454;#24211;#30340;#20840;#23616;#29305;#24615;#12290; ALTER DATABASE -- Edit this bug report at http://bugs.php.net/?id=40887edit=1
#40890 [Opn-Bgs]: long set_magic_quotes_gpc(int new_setting)
ID: 40890 Updated by: [EMAIL PROTECTED] Reported By: bothie at gmx dot de -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: any PHP Version: 5.2.1 New Comment: A new introduced function set_magic_quotes_gpc would change that as any program can enforce that setting in that way which it self expects it for it's own runtime. 1) magic quotes are finally removed in PHP6. 2) changing this setting in runtime does not affect the data, because quotes are applied _before_ the script execution started. Previous Comments: [2007-03-22 10:00:17] bothie at gmx dot de Description: Add functions like long set_magic_quotes_gpc(int new_setting) Having security in mind, many web application (WA) programmers expect magic_quotes_gpc to be set (or to be not set). It's possible to write WAs which can tolerate both settings but the most easiest ist to have just magic_quotes_gpc being set which is the default of course. But some sites have magic_quotes_gpc not set. So mixing WAs expecting magic_quotes_gpc to be set and WAs expecting magic_quotes_gpc not to be set is impossible. A new introduced function set_magic_quotes_gpc would change that as any program can enforce that setting in that way which it self expects it for it's own runtime. (This feature request should be seen a little bit more general, any other value which could be set in php.ini should get it's set_ counterpart as well except for some exceptions like disable_functions, for which a set- counterpart may not be so wise - or at least a set_disable_function should only be able to ADD additional functions to the set of disabled functions, not to REMOVE any of them specified in php.ini). (I've just seen the ini_set-function and am very disappointed about it NOT supporting a change to magic_quotes_gpc!) -- Edit this bug report at http://bugs.php.net/?id=40890edit=1
#40886 [Bgs-Opn]: static methods assigned to instances
ID: 40886
User updated by: andrea at 3site dot it
Reported By: andrea at 3site dot it
-Status: Bogus
+Status: Open
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
This cannot be an expected behaviour because in this way a static
method is exactly the same of a generic public method.
Static parameters aren't (correctly) usable with instances so why
static methods should be assigned?
If this is an expected behaviour please tell us what do You think
static keyword means and explain them correctly on documentation page.
Previous Comments:
[2007-03-21 21:02:53] [EMAIL PROTECTED]
Expected behaviour.
[2007-03-21 20:13:21] andrea at 3site dot it
damn ... http://www.php.net/manual/en/language.oop5.static.php
Declaring class members or methods as static makes them accessible
without needing an instantiation of the class. A member declared as
static can not be accessed with an instantiated class object (though a
static method can).
Well ... C# and other languages doesn't assign static methods to
instances.
C++ does it but it assign static parameters too.
With PHP 5 we can't use the same name for 2 different methods (for
example one static and one public) but we can call a static method
without static declaration (only E_STRICT tells us there's something
wrong) while C++ can't call a public method, or parameter, with a class
if it's not declared as static.
At this point, why did You introduce the static method/property type?
This implementation is not Object Oriented, it's quite Hilarius
Oriented.
Sorry for this bug (and for me it's really a bug!).
Regards.
[2007-03-21 18:56:54] andrea at 3site dot it
Description:
Description:
I don't know if it is by design, but this is not what I would expect
logically ... (and with static variables it doesn't happen so it should
be a _strange_ logic)
I suppose this problem is related with this one:
http://bugs.php.net/bug.php?id=40837
but I think this one is *not* callable Irrelevant
Reproduce code:
---
?php
class ExampleClass {
public static function StaticExample(){
echo StaticExample, br /;
}
public function InstanceExample(){
echo InstanceExample, br /;
}
}
$test = new ExampleClass();
ExampleClass::StaticExample(); // ok
$test-InstanceExample(); // ok
$test-StaticExample(); // what the hell?
?
Expected result:
StaticExample
InstanceExample
FATAL ERROR ... undefined method StaticExample
Actual result:
--
StaticExample
InstanceExample
StaticExample
--
Edit this bug report at http://bugs.php.net/?id=40886edit=1
#40886 [Com]: static methods assigned to instances
ID: 40886
Comment by: daniele_dll at yahoo dot it
Reported By: andrea at 3site dot it
Status: Open
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
Hi,
i was talking with andrea yesterday evening and he was explaining me
that stuff.
I don't know if it is an expected behaviour or not, but i'm sure that
somewhere there is a problem!
Infact, if it is an expected behaviour the static keyword loss it
meanings and, probably, slowdown the php page compilation/execution, but
if it is normal documentation should be fixed because it says a totally
different stuff.
However, to get back to the problem, the manual says, as should be:
A member declared as static can not be accessed with an instantiated
class object
Because is a non sense say that something is static and after let to
the code to call it as non static
Previous Comments:
[2007-03-22 11:19:48] andrea at 3site dot it
This cannot be an expected behaviour because in this way a static
method is exactly the same of a generic public method.
Static parameters aren't (correctly) usable with instances so why
static methods should be assigned?
If this is an expected behaviour please tell us what do You think
static keyword means and explain them correctly on documentation page.
[2007-03-21 21:02:53] [EMAIL PROTECTED]
Expected behaviour.
[2007-03-21 20:13:21] andrea at 3site dot it
damn ... http://www.php.net/manual/en/language.oop5.static.php
Declaring class members or methods as static makes them accessible
without needing an instantiation of the class. A member declared as
static can not be accessed with an instantiated class object (though a
static method can).
Well ... C# and other languages doesn't assign static methods to
instances.
C++ does it but it assign static parameters too.
With PHP 5 we can't use the same name for 2 different methods (for
example one static and one public) but we can call a static method
without static declaration (only E_STRICT tells us there's something
wrong) while C++ can't call a public method, or parameter, with a class
if it's not declared as static.
At this point, why did You introduce the static method/property type?
This implementation is not Object Oriented, it's quite Hilarius
Oriented.
Sorry for this bug (and for me it's really a bug!).
Regards.
[2007-03-21 18:56:54] andrea at 3site dot it
Description:
Description:
I don't know if it is by design, but this is not what I would expect
logically ... (and with static variables it doesn't happen so it should
be a _strange_ logic)
I suppose this problem is related with this one:
http://bugs.php.net/bug.php?id=40837
but I think this one is *not* callable Irrelevant
Reproduce code:
---
?php
class ExampleClass {
public static function StaticExample(){
echo StaticExample, br /;
}
public function InstanceExample(){
echo InstanceExample, br /;
}
}
$test = new ExampleClass();
ExampleClass::StaticExample(); // ok
$test-InstanceExample(); // ok
$test-StaticExample(); // what the hell?
?
Expected result:
StaticExample
InstanceExample
FATAL ERROR ... undefined method StaticExample
Actual result:
--
StaticExample
InstanceExample
StaticExample
--
Edit this bug report at http://bugs.php.net/?id=40886edit=1
#40886 [Opn-Fbk]: static methods assigned to instances
ID: 40886
Updated by: [EMAIL PROTECTED]
Reported By: andrea at 3site dot it
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
Previous Comments:
[2007-03-22 11:29:22] daniele_dll at yahoo dot it
Hi,
i was talking with andrea yesterday evening and he was explaining me
that stuff.
I don't know if it is an expected behaviour or not, but i'm sure that
somewhere there is a problem!
Infact, if it is an expected behaviour the static keyword loss it
meanings and, probably, slowdown the php page compilation/execution, but
if it is normal documentation should be fixed because it says a totally
different stuff.
However, to get back to the problem, the manual says, as should be:
A member declared as static can not be accessed with an instantiated
class object
Because is a non sense say that something is static and after let to
the code to call it as non static
[2007-03-22 11:19:48] andrea at 3site dot it
This cannot be an expected behaviour because in this way a static
method is exactly the same of a generic public method.
Static parameters aren't (correctly) usable with instances so why
static methods should be assigned?
If this is an expected behaviour please tell us what do You think
static keyword means and explain them correctly on documentation page.
[2007-03-21 21:02:53] [EMAIL PROTECTED]
Expected behaviour.
[2007-03-21 20:13:21] andrea at 3site dot it
damn ... http://www.php.net/manual/en/language.oop5.static.php
Declaring class members or methods as static makes them accessible
without needing an instantiation of the class. A member declared as
static can not be accessed with an instantiated class object (though a
static method can).
Well ... C# and other languages doesn't assign static methods to
instances.
C++ does it but it assign static parameters too.
With PHP 5 we can't use the same name for 2 different methods (for
example one static and one public) but we can call a static method
without static declaration (only E_STRICT tells us there's something
wrong) while C++ can't call a public method, or parameter, with a class
if it's not declared as static.
At this point, why did You introduce the static method/property type?
This implementation is not Object Oriented, it's quite Hilarius
Oriented.
Sorry for this bug (and for me it's really a bug!).
Regards.
[2007-03-21 18:56:54] andrea at 3site dot it
Description:
Description:
I don't know if it is by design, but this is not what I would expect
logically ... (and with static variables it doesn't happen so it should
be a _strange_ logic)
I suppose this problem is related with this one:
http://bugs.php.net/bug.php?id=40837
but I think this one is *not* callable Irrelevant
Reproduce code:
---
?php
class ExampleClass {
public static function StaticExample(){
echo StaticExample, br /;
}
public function InstanceExample(){
echo InstanceExample, br /;
}
}
$test = new ExampleClass();
ExampleClass::StaticExample(); // ok
$test-InstanceExample(); // ok
$test-StaticExample(); // what the hell?
?
Expected result:
StaticExample
InstanceExample
FATAL ERROR ... undefined method StaticExample
Actual result:
--
StaticExample
InstanceExample
StaticExample
--
Edit this bug report at http://bugs.php.net/?id=40886edit=1
#40886 [Fbk-Bgs]: static methods assigned to instances
ID: 40886 Updated by: [EMAIL PROTECTED] Reported By: andrea at 3site dot it -Status: Feedback +Status: Bogus Bug Type: Class/Object related Operating System: Windows XP SP2 PHP Version: 5.2.1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2007-03-22 12:15:28] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2007-03-22 11:29:22] daniele_dll at yahoo dot it Hi, i was talking with andrea yesterday evening and he was explaining me that stuff. I don't know if it is an expected behaviour or not, but i'm sure that somewhere there is a problem! Infact, if it is an expected behaviour the static keyword loss it meanings and, probably, slowdown the php page compilation/execution, but if it is normal documentation should be fixed because it says a totally different stuff. However, to get back to the problem, the manual says, as should be: A member declared as static can not be accessed with an instantiated class object Because is a non sense say that something is static and after let to the code to call it as non static [2007-03-22 11:19:48] andrea at 3site dot it This cannot be an expected behaviour because in this way a static method is exactly the same of a generic public method. Static parameters aren't (correctly) usable with instances so why static methods should be assigned? If this is an expected behaviour please tell us what do You think static keyword means and explain them correctly on documentation page. [2007-03-21 21:02:53] [EMAIL PROTECTED] Expected behaviour. [2007-03-21 20:13:21] andrea at 3site dot it damn ... http://www.php.net/manual/en/language.oop5.static.php Declaring class members or methods as static makes them accessible without needing an instantiation of the class. A member declared as static can not be accessed with an instantiated class object (though a static method can). Well ... C# and other languages doesn't assign static methods to instances. C++ does it but it assign static parameters too. With PHP 5 we can't use the same name for 2 different methods (for example one static and one public) but we can call a static method without static declaration (only E_STRICT tells us there's something wrong) while C++ can't call a public method, or parameter, with a class if it's not declared as static. At this point, why did You introduce the static method/property type? This implementation is not Object Oriented, it's quite Hilarius Oriented. Sorry for this bug (and for me it's really a bug!). Regards. 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/40886 -- Edit this bug report at http://bugs.php.net/?id=40886edit=1
#40886 [Bgs-Opn]: static methods assigned to instances
ID: 40886
User updated by: andrea at 3site dot it
Reported By: andrea at 3site dot it
-Status: Bogus
+Status: Open
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
Derick, this is a bug (any Object Oriented logic).
There's something wrong in your static keyword implementation, at least
for methods that uses static keyword.
This my last call and this is my last example:
?php
class ExampleClass {
public $StaticExample;
public final function __construct(){
// bye bye public *parameter*
$this-StaticExample = create_function('$never', 'return
welcome
PHP5 ambiguity;');
}
public final static function StaticExample(){
echo StaticExample, br /;
}
}
$test = new ExampleClass();
ExampleClass::StaticExample();
exit($test-StaticExample());
?
What does static keyword mean for PHP 5 developers?
If this is an expected behaviour you should explain them in
documentation page.
Regards (I'll never open again this *bug*)
Previous Comments:
[2007-03-22 12:18:16] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2007-03-22 12:15:28] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
[2007-03-22 11:29:22] daniele_dll at yahoo dot it
Hi,
i was talking with andrea yesterday evening and he was explaining me
that stuff.
I don't know if it is an expected behaviour or not, but i'm sure that
somewhere there is a problem!
Infact, if it is an expected behaviour the static keyword loss it
meanings and, probably, slowdown the php page compilation/execution, but
if it is normal documentation should be fixed because it says a totally
different stuff.
However, to get back to the problem, the manual says, as should be:
A member declared as static can not be accessed with an instantiated
class object
Because is a non sense say that something is static and after let to
the code to call it as non static
[2007-03-22 11:19:48] andrea at 3site dot it
This cannot be an expected behaviour because in this way a static
method is exactly the same of a generic public method.
Static parameters aren't (correctly) usable with instances so why
static methods should be assigned?
If this is an expected behaviour please tell us what do You think
static keyword means and explain them correctly on documentation page.
[2007-03-21 21:02:53] [EMAIL PROTECTED]
Expected behaviour.
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/40886
--
Edit this bug report at http://bugs.php.net/?id=40886edit=1
#33664 [Com]: Console window appears when using exec()
ID: 33664
Comment by: zynevich at jbaw dot iba dot by
Reported By: richard dot quadling at bandvulc dot co dot uk
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows
PHP Version: 5.0.4
New Comment:
Our customer runs PHP5.1.6. from XAMPP stack and when code simply call
shell_exec block cmd window appear (they use browser and web server on
the same machine -- light weight server application). When I recompiled
PHP with proposed changes bug disappeared.
Previous Comments:
[2005-07-12 16:44:36] richard dot quadling at bandvulc dot co dot uk
Description:
Hi.
I have a LOT of php scripts which are launched via Windows task
scheduler. They are executed using php-win.exe.
Nothing wrong so far.
Some of the scripts run other programs (e.g. WinRAR, NSLookup).
When these programs are launched, a black window (the console window)
appears.
This is REALLY bad. This takes focus away from what I am doing.
I'm using the php-win.exe which is supposed to NOT supply a console
box.
Now.
Having looked at the source, I see that when an external application is
called, it is invoked via the system command line interpreter. I've seen
the various discussions about this and its security implications.
Personally, I'd rather the command shell was NOT loaded, but ...
The real issue for me is that the command shell is launched and creates
a window.
I suggest the following changes to the PHP source.
/* $Id: tsrm_win32.c,v 1.26 2004/01/08 08:14:03 andi Exp $ */
Line 214
if (!CreateProcess(NULL, cmd, security, security,
security.bInheritHandle, NORMAL_PRIORITY_CLASS, env, cwd, startup,
process)) {
becomes
if (!CreateProcess(NULL, cmd, security, security,
security.bInheritHandle, NORMAL_PRIORITY_CLASS | CREATE_NO_WINDOW, env,
cwd, startup, process)) {
/* $Id: proc_open.c,v 1.35 2005/07/01 06:49:29 hyanantha Exp $ */
Line 748
newprocok = CreateProcess(NULL, command_with_cmd, security, security,
TRUE, NORMAL_PRIORITY_CLASS, env.envp, cwd, si, pi);
becomes
newprocok = CreateProcess(NULL, command_with_cmd, security, security,
TRUE, NORMAL_PRIORITY_CLASS | CREATE_NO_WINDOW, env.envp, cwd, si,
pi);
static const char rcsid[] = $Id: os_win32.c,v 1.6 2002/10/13 07:23:17
shane Exp $;
Line 1260 to 1269
success = CreateProcess(execPath, /* LPCSTR address of module name
*/
NULL, /* LPCSTR address of command line */
NULL, /* Process security attributes */
NULL, /* Thread security attributes */
TRUE, /* Inheritable Handes inherited. */
0, /* DWORD creation flags */
env, /* Use parent environment block */
NULL, /* Address of current directory name */
StartupInfo, /* Address of STARTUPINFO */
pInfo); /* Address of PROCESS_INFORMATION */
becomes
success = CreateProcess(execPath, /* LPCSTR address of module name
*/
NULL, /* LPCSTR address of command line */
NULL, /* Process security attributes */
NULL, /* Thread security attributes */
TRUE, /* Inheritable Handes inherited. */
NORMAL_PRIORITY_CLASS | CREATE_NO_WINDOW,
/* DWORD creation flags
*/
env, /* Use parent environment block */
NULL, /* Address of current directory name */
StartupInfo, /* Address of STARTUPINFO */
pInfo); /* Address of PROCESS_INFORMATION */
Ideally, the CREATE_NO_WINDOW should only be added (or OR'd :-)) if the
executable is not the normal php.exe (i.e. ISAPI, CGI, php-win.exe,
etc).
Regards,
Richard Quadling.
--
Edit this bug report at http://bugs.php.net/?id=33664edit=1
#40891 [NEW]: mysqli_stmt_bind_param should accept array of parameters to bind
From: john dot navratil at sbcglobal dot net Operating system: Fedora Core 5 PHP version: 5.2.1 PHP Bug Type: Feature/Change Request Bug description: mysqli_stmt_bind_param should accept array of parameters to bind Description: I've read bug #31096 and this is a variant of the same bug, but I beseech you to reconsider. The C API to mysql defines my_bool mysql_stmt_bind_param(MYSQL_STMT *stmt, MYSQL_BIND *bind) to accept an array of parameters to bind to a prepared statement. PHP 5.2.1 does not and requires the number of parameters to match both the number of characters in the type string (essentially an array of types) and the number of parameters in the prepared statement. This works well for static statements but makes dynamic statements impossible to prepare unless one resorts to something like: $arr = array-of-values-to-be-bound array_unshift($arr, $typeString); call_user_func_array(array( $mysqli, stmt_bind_param), $arr); array_shift($arr); One can argue that this is sufficient (a point which I will concede), but the beauty of PHP is not in its sufficiency (machine code is sufficient, ultimately) but in its expressivity. The foregoing is not very expressive, is tightly bound to the mysqli_stmt_bind_result signature, and does not mirror the underlying API (which is another PHP strong point). Would you please consider a variant which accepts two arguments with the second being an array of values to bind to the prepared statement? Thanks! -- Edit bug report at http://bugs.php.net/?id=40891edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40891r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40891r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40891r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40891r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40891r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40891r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40891r=needscript Try newer version:http://bugs.php.net/fix.php?id=40891r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40891r=support Expected behavior:http://bugs.php.net/fix.php?id=40891r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40891r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40891r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40891r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40891r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40891r=dst IIS Stability:http://bugs.php.net/fix.php?id=40891r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40891r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40891r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40891r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40891r=mysqlcfg
#40892 [NEW]: floating point rounding issue
From: fizz at beyond dot hjsoft dot com Operating system: linux, solaris PHP version: 5.2.1 PHP Bug Type: Math related Bug description: floating point rounding issue Description: When printing out a floating point number using printf (or storing it with sprintf, or casting it as an int) it gives an incorrect number. This appears to be due to floating point math being inaccurate. Reproduce code: --- ?php $val = 309; for ($x = 0; $x 950; $x++) $val += 0.001; var_dump($val); echo $val . \n; $val = $val * 100; var_dump($val); echo $val . \n; printf (%d\n, $val); echo (int)$val . \n; ? Expected result: float(309.95) 309.95 float(30995) 30995 30995 30995 Actual result: -- float(309.95) 309.95 float(30995) 30995 30994 30994 -- Edit bug report at http://bugs.php.net/?id=40892edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40892r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40892r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40892r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40892r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40892r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40892r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40892r=needscript Try newer version:http://bugs.php.net/fix.php?id=40892r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40892r=support Expected behavior:http://bugs.php.net/fix.php?id=40892r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40892r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40892r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40892r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40892r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40892r=dst IIS Stability:http://bugs.php.net/fix.php?id=40892r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40892r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40892r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40892r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40892r=mysqlcfg
#40892 [Opn-Bgs]: floating point rounding issue
ID: 40892 Updated by: [EMAIL PROTECTED] Reported By: fizz at beyond dot hjsoft dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: linux, solaris PHP Version: 5.2.1 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. Previous Comments: [2007-03-22 14:13:24] fizz at beyond dot hjsoft dot com Description: When printing out a floating point number using printf (or storing it with sprintf, or casting it as an int) it gives an incorrect number. This appears to be due to floating point math being inaccurate. Reproduce code: --- ?php $val = 309; for ($x = 0; $x 950; $x++) $val += 0.001; var_dump($val); echo $val . \n; $val = $val * 100; var_dump($val); echo $val . \n; printf (%d\n, $val); echo (int)$val . \n; ? Expected result: float(309.95) 309.95 float(30995) 30995 30995 30995 Actual result: -- float(309.95) 309.95 float(30995) 30995 30994 30994 -- Edit this bug report at http://bugs.php.net/?id=40892edit=1
#40892 [Bgs]: floating point rounding issue
ID: 40892 User updated by: fizz at beyond dot hjsoft dot com Reported By: fizz at beyond dot hjsoft dot com Status: Bogus Bug Type: Math related Operating System: linux, solaris PHP Version: 5.2.1 New Comment: I very much understand that, my concern was more of a consistency issue between how echo and var_dump does it (which outputs the correct information) and how printf/sprintf does (which gives incorrect output). Previous Comments: [2007-03-22 14:23:26] [EMAIL PROTECTED] Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. [2007-03-22 14:13:24] fizz at beyond dot hjsoft dot com Description: When printing out a floating point number using printf (or storing it with sprintf, or casting it as an int) it gives an incorrect number. This appears to be due to floating point math being inaccurate. Reproduce code: --- ?php $val = 309; for ($x = 0; $x 950; $x++) $val += 0.001; var_dump($val); echo $val . \n; $val = $val * 100; var_dump($val); echo $val . \n; printf (%d\n, $val); echo (int)$val . \n; ? Expected result: float(309.95) 309.95 float(30995) 30995 30995 30995 Actual result: -- float(309.95) 309.95 float(30995) 30995 30994 30994 -- Edit this bug report at http://bugs.php.net/?id=40892edit=1
#40886 [Opn-Bgs]: static methods assigned to instances
ID: 40886
Updated by: [EMAIL PROTECTED]
Reported By: andrea at 3site dot it
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
this bug really shows how one person's bug is another person's
feature. :)
the syntax $a-method() allows you to call a static method of the
class that $a is an instantiated object of, something I find useful
for objects that contain static methods in a parent/child
inheritance hierarchy. Using $a-method(), I don't need to do
hackery to figure out which class $a is in order to call one of
its static methods. Consider the alternative:
?php
call_user_func_array(get_class($a), 'method', $args);
?
The above is the only alternative (save using reflection, which is
even more verbose and inefficient) to:
?php
$a-method($arg1, $arg1);
?
Which syntax do you prefer?
The big difference between php 4 and php 5 is that a method declared
as static does not have $this set. You'll get a fatal error, in
fact, if you try to use $this in a static method.
Why do you care so much about whether it's called with
class::method() or $this-method()? You can't have two methods with
the same name, one static and one non-static, so there is no
possibility of accidentally calling the wrong one.
If you are wanting absolutely perfect OO, there are plenty of
other languages that will provide exactly the straightjacket and
punishment you desire. If you want to code efficient, easy to
maintain, working programs, use PHP.
Previous Comments:
[2007-03-22 12:28:44] andrea at 3site dot it
Derick, this is a bug (any Object Oriented logic).
There's something wrong in your static keyword implementation, at least
for methods that uses static keyword.
This my last call and this is my last example:
?php
class ExampleClass {
public $StaticExample;
public final function __construct(){
// bye bye public *parameter*
$this-StaticExample = create_function('$never', 'return
welcome
PHP5 ambiguity;');
}
public final static function StaticExample(){
echo StaticExample, br /;
}
}
$test = new ExampleClass();
ExampleClass::StaticExample();
exit($test-StaticExample());
?
What does static keyword mean for PHP 5 developers?
If this is an expected behaviour you should explain them in
documentation page.
Regards (I'll never open again this *bug*)
[2007-03-22 12:18:16] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2007-03-22 12:15:28] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
[2007-03-22 11:29:22] daniele_dll at yahoo dot it
Hi,
i was talking with andrea yesterday evening and he was explaining me
that stuff.
I don't know if it is an expected behaviour or not, but i'm sure that
somewhere there is a problem!
Infact, if it is an expected behaviour the static keyword loss it
meanings and, probably, slowdown the php page compilation/execution, but
if it is normal documentation should be fixed because it says a totally
different stuff.
However, to get back to the problem, the manual says, as should be:
A member declared as static can not be accessed with an instantiated
class object
Because is a non sense say that something is static and after let to
the code to call it as non static
[2007-03-22 11:19:48] andrea at 3site dot it
This cannot be an expected behaviour because in this way a static
method is exactly the same of a generic public method.
Static parameters aren't (correctly) usable with instances so why
static methods should be assigned?
If this is an expected behaviour please tell us what do You think
static keyword means and explain them correctly on documentation page.
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/40886
--
Edit this bug report at http://bugs.php.net/?id=40886edit=1
#40893 [NEW]: PHP reports wrong total and free space for NFS-mounted filesystems on RedHat
From: andrew at digicol dot de Operating system: Redhat EL4 PHP version: 4.4.5 PHP Bug Type: Filesystem function related Bug description: PHP reports wrong total and free space for NFS-mounted filesystems on RedHat Description: disk_total_space, disk_free_space reports wrong total and free space for NFS-mounted filesystems on RedHat Linux. This bug seems to be the related to #39520, if not the same. #39520 has been rated as 'bogus' which I think is a mistake. Please re-consider. The bug shows on RedHat Linux, but not SuSE Linux. This might ultimately be considered as a RedHat bug or of the libraries used there, but other commands (df) that use the statfs system call show the correct file system size / free space. It may be argued (like in #39520) that the wrong block size parameter is used to calculate total or free disk space. strace df -h shows RedHat and SuSE report different f_frsize, but same f_bsize on the same NFS share, but df reports the correct size on both. Reproduce code: --- Test: Mount a NFS share on a RedHat system and on a SuSE Linux system. 1) RedHat 2.6.9-34.EL, 32-bit [EMAIL PROTECTED] /]# mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt [EMAIL PROTECTED] /]# df -h Filesystem Size Used Avail Use% Mounted on ... 10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt [EMAIL PROTECTED] /]# /dot/dc/bin/php/bin/php -r 'echo_number_format(disk_total_space(/mnt)) . \n;' 37,512,204,288== Wrong size, seems to be real size / 8 2) SuSE Linux 9.3 32-bit suse:/ # mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt suse:/ # df -h Filesystem Size Used Avail Use% Mounted on ... 10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt suse:/ # php -r 'echo number_format(disk_total_space(/mnt)) . \n;' 300,097,634,304== Correct. Expected result: I would expect the result to be 300G on both systems. Actual result: -- Reports 300G on SuSE Linux, around 35G only on RedHat. -- Edit bug report at http://bugs.php.net/?id=40893edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40893r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40893r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40893r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40893r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40893r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40893r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40893r=needscript Try newer version:http://bugs.php.net/fix.php?id=40893r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40893r=support Expected behavior:http://bugs.php.net/fix.php?id=40893r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40893r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40893r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40893r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40893r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40893r=dst IIS Stability:http://bugs.php.net/fix.php?id=40893r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40893r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40893r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40893r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40893r=mysqlcfg
#40893 [Opn]: PHP reports wrong total and free space for NFS-mounted filesystems on RedHat
ID: 40893 User updated by: andrew at digicol dot de Reported By: andrew at digicol dot de Status: Open Bug Type: Filesystem function related Operating System: Redhat EL4 PHP Version: 4.4.5 New Comment: PHP version seems to be irrelevant, but I was forced to choose a version because of the bug category. I couldn't find the versions I tried it on (4.3.9, 5.2.0) in the version drop-down. Previous Comments: [2007-03-22 14:59:05] andrew at digicol dot de Description: disk_total_space, disk_free_space reports wrong total and free space for NFS-mounted filesystems on RedHat Linux. This bug seems to be the related to #39520, if not the same. #39520 has been rated as 'bogus' which I think is a mistake. Please re-consider. The bug shows on RedHat Linux, but not SuSE Linux. This might ultimately be considered as a RedHat bug or of the libraries used there, but other commands (df) that use the statfs system call show the correct file system size / free space. It may be argued (like in #39520) that the wrong block size parameter is used to calculate total or free disk space. strace df -h shows RedHat and SuSE report different f_frsize, but same f_bsize on the same NFS share, but df reports the correct size on both. Reproduce code: --- Test: Mount a NFS share on a RedHat system and on a SuSE Linux system. 1) RedHat 2.6.9-34.EL, 32-bit [EMAIL PROTECTED] /]# mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt [EMAIL PROTECTED] /]# df -h Filesystem Size Used Avail Use% Mounted on ... 10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt [EMAIL PROTECTED] /]# /dot/dc/bin/php/bin/php -r 'echo_number_format(disk_total_space(/mnt)) . \n;' 37,512,204,288== Wrong size, seems to be real size / 8 2) SuSE Linux 9.3 32-bit suse:/ # mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt suse:/ # df -h Filesystem Size Used Avail Use% Mounted on ... 10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt suse:/ # php -r 'echo number_format(disk_total_space(/mnt)) . \n;' 300,097,634,304== Correct. Expected result: I would expect the result to be 300G on both systems. Actual result: -- Reports 300G on SuSE Linux, around 35G only on RedHat. -- Edit this bug report at http://bugs.php.net/?id=40893edit=1
#40893 [Opn-Fbk]: PHP reports wrong total and free space for NFS-mounted filesystems on RedHat
ID: 40893 Updated by: [EMAIL PROTECTED] Reported By: andrew at digicol dot de -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Redhat EL4 PHP Version: 4.4.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2007-03-22 15:06:32] andrew at digicol dot de PHP version seems to be irrelevant, but I was forced to choose a version because of the bug category. I couldn't find the versions I tried it on (4.3.9, 5.2.0) in the version drop-down. [2007-03-22 14:59:05] andrew at digicol dot de Description: disk_total_space, disk_free_space reports wrong total and free space for NFS-mounted filesystems on RedHat Linux. This bug seems to be the related to #39520, if not the same. #39520 has been rated as 'bogus' which I think is a mistake. Please re-consider. The bug shows on RedHat Linux, but not SuSE Linux. This might ultimately be considered as a RedHat bug or of the libraries used there, but other commands (df) that use the statfs system call show the correct file system size / free space. It may be argued (like in #39520) that the wrong block size parameter is used to calculate total or free disk space. strace df -h shows RedHat and SuSE report different f_frsize, but same f_bsize on the same NFS share, but df reports the correct size on both. Reproduce code: --- Test: Mount a NFS share on a RedHat system and on a SuSE Linux system. 1) RedHat 2.6.9-34.EL, 32-bit [EMAIL PROTECTED] /]# mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt [EMAIL PROTECTED] /]# df -h Filesystem Size Used Avail Use% Mounted on ... 10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt [EMAIL PROTECTED] /]# /dot/dc/bin/php/bin/php -r 'echo_number_format(disk_total_space(/mnt)) . \n;' 37,512,204,288== Wrong size, seems to be real size / 8 2) SuSE Linux 9.3 32-bit suse:/ # mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt suse:/ # df -h Filesystem Size Used Avail Use% Mounted on ... 10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt suse:/ # php -r 'echo number_format(disk_total_space(/mnt)) . \n;' 300,097,634,304== Correct. Expected result: I would expect the result to be 300G on both systems. Actual result: -- Reports 300G on SuSE Linux, around 35G only on RedHat. -- Edit this bug report at http://bugs.php.net/?id=40893edit=1
#40893 [Fbk-Opn]: PHP reports wrong total and free space for NFS-mounted filesystems on RedHat
ID: 40893
User updated by: andrew at digicol dot de
Reported By: andrew at digicol dot de
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Redhat EL4
PHP Version: 4.4.5
New Comment:
RedHat Linux:
strace /dot/dc/bin/php/bin/php -r 'echo
number_format(disk_total_space(/mnt)) . \n;'
...
statfs(/mnt, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093458, f_bavail=5093458, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
...
SuSE Linux:
strace php -r 'echo number_format(disk_total_space(/mnt)) . \n;'
...
statfs(/mnt, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093458, f_bavail=5093458, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=32768}) = 0
...
Just in case this helps, df -h seems to invoke the a different system
call (statfs64, both systems are 32-bit, I am not an expert regarding
system calls). They result in the same f_bsize and fr_size values.
Unlike php, df draws the correct conclusions regarding total / free
space on both systems:
RedHat Linux:
strace df -h
...
statfs64(/mnt, 84, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093460, f_bavail=5093460, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
...
SuSE Linux:
strace df -h
...
statfs64(/mnt, 84, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093460, f_bavail=5093460, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=32768}) = 0
...
Previous Comments:
[2007-03-22 15:21:36] [EMAIL PROTECTED]
If you're still able to reproduce it - try to trace it and figure out
which blocksize is reported by the system and which function is used -
statvfs() or statfs().
[2007-03-22 15:17:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2007-03-22 15:06:32] andrew at digicol dot de
PHP version seems to be irrelevant, but I was forced to choose a
version because of the bug category. I couldn't find the versions I
tried it on (4.3.9, 5.2.0) in the version drop-down.
[2007-03-22 14:59:05] andrew at digicol dot de
Description:
disk_total_space, disk_free_space reports wrong total and free space
for NFS-mounted filesystems on RedHat Linux.
This bug seems to be the related to #39520, if not the same. #39520 has
been rated as 'bogus' which I think is a mistake. Please re-consider.
The bug shows on RedHat Linux, but not SuSE Linux. This might
ultimately be considered as a RedHat bug or of the libraries used there,
but other commands (df) that use the statfs system call show the correct
file system size / free space.
It may be argued (like in #39520) that the wrong block size parameter
is used to calculate total or free disk space. strace df -h shows RedHat
and SuSE report different f_frsize, but same f_bsize on the same NFS
share, but df reports the correct size on both.
Reproduce code:
---
Test: Mount a NFS share on a RedHat system and on a SuSE Linux system.
1) RedHat 2.6.9-34.EL, 32-bit
[EMAIL PROTECTED] /]# mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt
[EMAIL PROTECTED] /]# df -h
Filesystem Size Used Avail Use% Mounted on
...
10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt
[EMAIL PROTECTED] /]# /dot/dc/bin/php/bin/php -r
'echo_number_format(disk_total_space(/mnt)) . \n;'
37,512,204,288== Wrong size, seems to be real size / 8
2) SuSE Linux 9.3 32-bit
suse:/ # mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt
suse:/ # df -h
Filesystem Size Used Avail Use% Mounted on
...
10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt
suse:/ # php -r 'echo number_format(disk_total_space(/mnt)) . \n;'
300,097,634,304== Correct.
Expected result:
I would expect the result to be 300G on both systems.
Actual result:
--
Reports 300G on SuSE Linux, around 35G only on RedHat.
--
Edit this bug report at http://bugs.php.net/?id=40893edit=1
#33664 [Opn]: Console window appears when using exec()
ID: 33664
User updated by: richard dot quadling at bandvulc dot co dot uk
Reported By: richard dot quadling at bandvulc dot co dot uk
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows
-PHP Version: 5.0.4
+PHP Version: 5.2.2-dev
New Comment:
Patches for this...
Index: tsrm_win32.c
===
RCS file: /repository/TSRM/tsrm_win32.c,v
retrieving revision 1.31
diff -u -r1.31 tsrm_win32.c
--- tsrm_win32.c20 Mar 2007 17:57:44 - 1.31
+++ tsrm_win32.c22 Mar 2007 15:39:50 -
@@ -219,7 +219,7 @@
cmd = (char*)malloc(strlen(command)+strlen(TWG(comspec))+sizeof( /c
));
sprintf(cmd, %s /c %s, TWG(comspec), command);
- if (!CreateProcess(NULL, cmd, security, security,
security.bInheritHandle, NORMAL_PRIORITY_CLASS, env, cwd, startup,
process)) {
+ if (!CreateProcess(NULL, cmd, security, security,
security.bInheritHandle, NORMAL_PRIORITY_CLASS | CREATE_NO_WINDOW, env,
cwd, startup, process)) {
return NULL;
}
free(cmd);
and
Index: proc_open.c
===
RCS file: /repository/php-src/ext/standard/proc_open.c,v
retrieving revision 1.54
diff -u -r1.54 proc_open.c
--- proc_open.c 24 Feb 2007 16:25:55 - 1.54
+++ proc_open.c 22 Mar 2007 15:39:17 -
@@ -738,11 +738,11 @@
}
if (bypass_shell) {
- newprocok = CreateProcess(NULL, command, security, security,
TRUE,
NORMAL_PRIORITY_CLASS, env.envp, cwd, si, pi);
+ newprocok = CreateProcess(NULL, command, security, security,
TRUE,
NORMAL_PRIORITY_CLASS | CREATE_NO_WINDOW, env.envp, cwd, si, pi);
} else {
spprintf(command_with_cmd, 0, %s /c %s, GetVersion()
0x8000
? COMSPEC_NT : COMSPEC_9X, command);
- newprocok = CreateProcess(NULL, command_with_cmd, security,
security, TRUE, NORMAL_PRIORITY_CLASS, env.envp, cwd, si, pi);
+ newprocok = CreateProcess(NULL, command_with_cmd, security,
security, TRUE, NORMAL_PRIORITY_CLASS | CREATE_NO_WINDOW, env.envp,
cwd, si, pi);
efree(command_with_cmd);
}
Previous Comments:
[2007-03-22 13:12:59] zynevich at jbaw dot iba dot by
Our customer runs PHP5.1.6. from XAMPP stack and when code simply call
shell_exec block cmd window appear (they use browser and web server on
the same machine -- light weight server application). When I recompiled
PHP with proposed changes bug disappeared.
[2005-07-12 16:44:36] richard dot quadling at bandvulc dot co dot uk
Description:
Hi.
I have a LOT of php scripts which are launched via Windows task
scheduler. They are executed using php-win.exe.
Nothing wrong so far.
Some of the scripts run other programs (e.g. WinRAR, NSLookup).
When these programs are launched, a black window (the console window)
appears.
This is REALLY bad. This takes focus away from what I am doing.
I'm using the php-win.exe which is supposed to NOT supply a console
box.
Now.
Having looked at the source, I see that when an external application is
called, it is invoked via the system command line interpreter. I've seen
the various discussions about this and its security implications.
Personally, I'd rather the command shell was NOT loaded, but ...
The real issue for me is that the command shell is launched and creates
a window.
I suggest the following changes to the PHP source.
/* $Id: tsrm_win32.c,v 1.26 2004/01/08 08:14:03 andi Exp $ */
Line 214
if (!CreateProcess(NULL, cmd, security, security,
security.bInheritHandle, NORMAL_PRIORITY_CLASS, env, cwd, startup,
process)) {
becomes
if (!CreateProcess(NULL, cmd, security, security,
security.bInheritHandle, NORMAL_PRIORITY_CLASS | CREATE_NO_WINDOW, env,
cwd, startup, process)) {
/* $Id: proc_open.c,v 1.35 2005/07/01 06:49:29 hyanantha Exp $ */
Line 748
newprocok = CreateProcess(NULL, command_with_cmd, security, security,
TRUE, NORMAL_PRIORITY_CLASS, env.envp, cwd, si, pi);
becomes
newprocok = CreateProcess(NULL, command_with_cmd, security, security,
TRUE, NORMAL_PRIORITY_CLASS | CREATE_NO_WINDOW, env.envp, cwd, si,
pi);
static const char rcsid[] = $Id: os_win32.c,v 1.6 2002/10/13 07:23:17
shane Exp $;
Line 1260 to 1269
success = CreateProcess(execPath, /* LPCSTR address of module name
*/
NULL, /* LPCSTR address of command line */
NULL, /* Process security attributes */
NULL, /* Thread security attributes */
TRUE, /* Inheritable Handes inherited. */
0, /* DWORD creation flags */
env,
#40893 [Fbk]: PHP reports wrong total and free space for NFS-mounted filesystems on RedHat
ID: 40893 Updated by: [EMAIL PROTECTED] Reported By: andrew at digicol dot de Status: Feedback Bug Type: Filesystem function related Operating System: Redhat EL4 PHP Version: 4.4.5 New Comment: If you're still able to reproduce it - try to trace it and figure out which blocksize is reported by the system and which function is used - statvfs() or statfs(). Previous Comments: [2007-03-22 15:17:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2007-03-22 15:06:32] andrew at digicol dot de PHP version seems to be irrelevant, but I was forced to choose a version because of the bug category. I couldn't find the versions I tried it on (4.3.9, 5.2.0) in the version drop-down. [2007-03-22 14:59:05] andrew at digicol dot de Description: disk_total_space, disk_free_space reports wrong total and free space for NFS-mounted filesystems on RedHat Linux. This bug seems to be the related to #39520, if not the same. #39520 has been rated as 'bogus' which I think is a mistake. Please re-consider. The bug shows on RedHat Linux, but not SuSE Linux. This might ultimately be considered as a RedHat bug or of the libraries used there, but other commands (df) that use the statfs system call show the correct file system size / free space. It may be argued (like in #39520) that the wrong block size parameter is used to calculate total or free disk space. strace df -h shows RedHat and SuSE report different f_frsize, but same f_bsize on the same NFS share, but df reports the correct size on both. Reproduce code: --- Test: Mount a NFS share on a RedHat system and on a SuSE Linux system. 1) RedHat 2.6.9-34.EL, 32-bit [EMAIL PROTECTED] /]# mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt [EMAIL PROTECTED] /]# df -h Filesystem Size Used Avail Use% Mounted on ... 10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt [EMAIL PROTECTED] /]# /dot/dc/bin/php/bin/php -r 'echo_number_format(disk_total_space(/mnt)) . \n;' 37,512,204,288== Wrong size, seems to be real size / 8 2) SuSE Linux 9.3 32-bit suse:/ # mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt suse:/ # df -h Filesystem Size Used Avail Use% Mounted on ... 10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt suse:/ # php -r 'echo number_format(disk_total_space(/mnt)) . \n;' 300,097,634,304== Correct. Expected result: I would expect the result to be 300G on both systems. Actual result: -- Reports 300G on SuSE Linux, around 35G only on RedHat. -- Edit this bug report at http://bugs.php.net/?id=40893edit=1
#40894 [NEW]: fix for bug #38770 causes more harm than good on big-endian 64bit
From: mmarek at suse dot cz Operating system: PHP version: 5.2.1 PHP Bug Type: *Programming Data Structures Bug description: fix for bug #38770 causes more harm than good on big-endian 64bit Description: Fix for bug #38770 breaks unpack() on big-endian 64bit, because it reads uninitialized memory or memory that doesn't relate to the data being processed. In http://cvs.php.net/viewvc.cgi/php-src/ext/standard/pack.c?r1=1.62r2=1.63 input[inputpos + machine_endian_long_map[3]] will read input[inputpos+7] when unpacking 4 bytes. Please revert the fix, as it tries to fix a questionable issue (-3 simply doesn't fit into unsigned type) and causes trouble in cases where it worked before (eg. pear is not even installable on POWER, b/c install-pear-nozlib.phar makes heavy use of unpack()). Reproduce code: --- run print_r( unpack( V, pack( V, 200 ) )); several times on ppc64. Expected result: It should output Array ( [1] = 200 ) all the time. Actual result: -- # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = 200 ) # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = -2147483448 ) # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = 200 ) # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = 200 ) # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = -2147483448 ) -- Edit bug report at http://bugs.php.net/?id=40894edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40894r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40894r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40894r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40894r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40894r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40894r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40894r=needscript Try newer version:http://bugs.php.net/fix.php?id=40894r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40894r=support Expected behavior:http://bugs.php.net/fix.php?id=40894r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40894r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40894r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40894r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40894r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40894r=dst IIS Stability:http://bugs.php.net/fix.php?id=40894r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40894r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40894r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40894r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40894r=mysqlcfg
#40886 [Bgs]: static methods assigned to instances
ID: 40886
User updated by: andrea at 3site dot it
Reported By: andrea at 3site dot it
Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
That's what I think about this feature.
http://webreflection.blogspot.com/2007/03/php-5-developers-teach-us-what-does.html
If a method is static, it should be static ... with PHP 5 a static
method become an instance method (not static) ... what a feature!
The solution is to remove static keyword from my static methods, well
done!
I hope PHP 6 will not have this ambiguity, regards.
Previous Comments:
[2007-03-22 14:51:05] [EMAIL PROTECTED]
this bug really shows how one person's bug is another person's
feature. :)
the syntax $a-method() allows you to call a static method of the
class that $a is an instantiated object of, something I find useful
for objects that contain static methods in a parent/child
inheritance hierarchy. Using $a-method(), I don't need to do
hackery to figure out which class $a is in order to call one of
its static methods. Consider the alternative:
?php
call_user_func_array(get_class($a), 'method', $args);
?
The above is the only alternative (save using reflection, which is
even more verbose and inefficient) to:
?php
$a-method($arg1, $arg1);
?
Which syntax do you prefer?
The big difference between php 4 and php 5 is that a method declared
as static does not have $this set. You'll get a fatal error, in
fact, if you try to use $this in a static method.
Why do you care so much about whether it's called with
class::method() or $this-method()? You can't have two methods with
the same name, one static and one non-static, so there is no
possibility of accidentally calling the wrong one.
If you are wanting absolutely perfect OO, there are plenty of
other languages that will provide exactly the straightjacket and
punishment you desire. If you want to code efficient, easy to
maintain, working programs, use PHP.
[2007-03-22 12:28:44] andrea at 3site dot it
Derick, this is a bug (any Object Oriented logic).
There's something wrong in your static keyword implementation, at least
for methods that uses static keyword.
This my last call and this is my last example:
?php
class ExampleClass {
public $StaticExample;
public final function __construct(){
// bye bye public *parameter*
$this-StaticExample = create_function('$never', 'return
welcome
PHP5 ambiguity;');
}
public final static function StaticExample(){
echo StaticExample, br /;
}
}
$test = new ExampleClass();
ExampleClass::StaticExample();
exit($test-StaticExample());
?
What does static keyword mean for PHP 5 developers?
If this is an expected behaviour you should explain them in
documentation page.
Regards (I'll never open again this *bug*)
[2007-03-22 12:18:16] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2007-03-22 12:15:28] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
[2007-03-22 11:29:22] daniele_dll at yahoo dot it
Hi,
i was talking with andrea yesterday evening and he was explaining me
that stuff.
I don't know if it is an expected behaviour or not, but i'm sure that
somewhere there is a problem!
Infact, if it is an expected behaviour the static keyword loss it
meanings and, probably, slowdown the php page compilation/execution, but
if it is normal documentation should be fixed because it says a totally
different stuff.
However, to get back to the problem, the manual says, as should be:
A member declared as static can not be accessed with an instantiated
class object
Because is a non sense say that something is static and after let to
the code to call it as non static
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/40886
--
Edit this bug report at http://bugs.php.net/?id=40886edit=1
#40894 [Opn-Asn]: fix for bug #38770 causes more harm than good on big-endian 64bit
ID: 40894 Updated by: [EMAIL PROTECTED] Reported By: mmarek at suse dot cz -Status: Open +Status: Assigned Bug Type:*Programming Data Structures PHP Version: 5.2.1 -Assigned To: +Assigned To: iliaa Previous Comments: [2007-03-22 15:59:03] mmarek at suse dot cz Description: Fix for bug #38770 breaks unpack() on big-endian 64bit, because it reads uninitialized memory or memory that doesn't relate to the data being processed. In http://cvs.php.net/viewvc.cgi/php-src/ext/standard/pack.c?r1=1.62r2=1.63 input[inputpos + machine_endian_long_map[3]] will read input[inputpos+7] when unpacking 4 bytes. Please revert the fix, as it tries to fix a questionable issue (-3 simply doesn't fit into unsigned type) and causes trouble in cases where it worked before (eg. pear is not even installable on POWER, b/c install-pear-nozlib.phar makes heavy use of unpack()). Reproduce code: --- run print_r( unpack( V, pack( V, 200 ) )); several times on ppc64. Expected result: It should output Array ( [1] = 200 ) all the time. Actual result: -- # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = 200 ) # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = -2147483448 ) # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = 200 ) # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = 200 ) # ./sapi/cli/php -r 'print_r( unpack( V, pack( V, 200 ) ));' Array ( [1] = -2147483448 ) -- Edit this bug report at http://bugs.php.net/?id=40894edit=1
#40893 [Opn-Fbk]: PHP reports wrong total and free space for NFS-mounted filesystems on RedHat
ID: 40893
Updated by: [EMAIL PROTECTED]
Reported By: andrew at digicol dot de
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Redhat EL4
PHP Version: 4.4.5
New Comment:
From what I can see in df sources, it uses exactly the same logics as
PHP, so I don't really see how it's possible that you get correct values
with df, especially taking into account that the f_frsize is broken in
the same way there.
You might want to look at this RH bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146427
It says that RHEL3 U4 fixes it.
Previous Comments:
[2007-03-22 15:38:21] andrew at digicol dot de
RedHat Linux:
strace /dot/dc/bin/php/bin/php -r 'echo
number_format(disk_total_space(/mnt)) . \n;'
...
statfs(/mnt, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093458, f_bavail=5093458, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
...
SuSE Linux:
strace php -r 'echo number_format(disk_total_space(/mnt)) . \n;'
...
statfs(/mnt, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093458, f_bavail=5093458, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=32768}) = 0
...
Just in case this helps, df -h seems to invoke the a different system
call (statfs64, both systems are 32-bit, I am not an expert regarding
system calls). They result in the same f_bsize and fr_size values.
Unlike php, df draws the correct conclusions regarding total / free
space on both systems:
RedHat Linux:
strace df -h
...
statfs64(/mnt, 84, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093460, f_bavail=5093460, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
...
SuSE Linux:
strace df -h
...
statfs64(/mnt, 84, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093460, f_bavail=5093460, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=32768}) = 0
...
[2007-03-22 15:21:36] [EMAIL PROTECTED]
If you're still able to reproduce it - try to trace it and figure out
which blocksize is reported by the system and which function is used -
statvfs() or statfs().
[2007-03-22 15:17:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2007-03-22 15:06:32] andrew at digicol dot de
PHP version seems to be irrelevant, but I was forced to choose a
version because of the bug category. I couldn't find the versions I
tried it on (4.3.9, 5.2.0) in the version drop-down.
[2007-03-22 14:59:05] andrew at digicol dot de
Description:
disk_total_space, disk_free_space reports wrong total and free space
for NFS-mounted filesystems on RedHat Linux.
This bug seems to be the related to #39520, if not the same. #39520 has
been rated as 'bogus' which I think is a mistake. Please re-consider.
The bug shows on RedHat Linux, but not SuSE Linux. This might
ultimately be considered as a RedHat bug or of the libraries used there,
but other commands (df) that use the statfs system call show the correct
file system size / free space.
It may be argued (like in #39520) that the wrong block size parameter
is used to calculate total or free disk space. strace df -h shows RedHat
and SuSE report different f_frsize, but same f_bsize on the same NFS
share, but df reports the correct size on both.
Reproduce code:
---
Test: Mount a NFS share on a RedHat system and on a SuSE Linux system.
1) RedHat 2.6.9-34.EL, 32-bit
[EMAIL PROTECTED] /]# mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt
[EMAIL PROTECTED] /]# df -h
Filesystem Size Used Avail Use% Mounted on
...
10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt
[EMAIL PROTECTED] /]# /dot/dc/bin/php/bin/php -r
'echo_number_format(disk_total_space(/mnt)) . \n;'
37,512,204,288== Wrong size, seems to be real size / 8
2) SuSE Linux 9.3 32-bit
suse:/ # mount -t nfs 10.20.0.178:/dot/oracle_dump /mnt
suse:/ # df -h
Filesystem Size Used Avail Use% Mounted on
...
10.20.0.178:/dot/oracle_dump 280G 125G 156G 45% /mnt
suse:/ # php -r 'echo number_format(disk_total_space(/mnt)) . \n;'
300,097,634,304== Correct.
Expected result:
I would expect the result to be 300G on both systems.
Actual result:
--
Reports 300G on SuSE Linux, around 35G only on RedHat.
--
Edit this bug report at http://bugs.php.net/?id=40893edit=1
#40895 [NEW]: Problem for ending http_requests with Keep-Alive
From: allali at labri dot fr
Operating system: Linux
PHP version: 5.2.1
PHP Bug Type: Output Control
Bug description: Problem for ending http_requests with Keep-Alive
Description:
The problem is that I have a script which is called twice by the same
brother using a Http connection with the Keep Alive attibute.
For the first call:
I notify the end of the answer as follow:
===
ignore_user_abort(true);
$msg=toto;
header(Content-Length: .strlen($msg));
echo $msg;
flush();
... some long time stuff here=
===
the browser read the answer and then I ask again for the same page using
the same tcp connection (Keep-alive).
In the second call, the output is blocked until the first call process is
dead. Thus its execution is suspended until the long time stuff is done.
(I see the http request using tcpdump).
If I put the following for the first call:
header(Cache-Control: no-cache, must-revalidate);
header(Expires: Mon, 26 Jul 1997 05:00:00 GMT);
header(Connection: close);
$msg=toto;
header(Content-Length: .strlen($msg));
echo $msg;
flush();
=
then all work fine except that the connection is effectively closed by the
browser and then re-open which implies a great lost of performances.
Also I did not find any mechanism (bug?) in php to indicate that the
response is done. (like http_close or fclose(STDOUT) // STDOUT doesn't
exists...). Maybe, php is suppose to guess that using the Content-Length
(bug?).
Perhaps it is apache which is waiting for the end of the process or the
closing of the standard process output.
Finally, I think this become critical in AJAX aplications.
Thx
J.A.
Reproduce code:
---
? // hello.php
if (isset($_GET[a])==false){
ignore_user_abort(true);
$msg=hello;
header(Content-Length: .strlen($msg));
if (isset($_GET[close])){
header(Cache-Control: no-cache, must-revalidate);
header(Expires: Mon, 26 Jul 1997 05:00:00 GMT);
header(Connection: close);
}
echo $msg;
flush();
sleep(20);
}
else{
echo world!;
}
?
Expected result:
just call the script twice:
hello.php
= hello
hello.php?a
= world!
immediately
Actual result:
--
just call the script twice:
hello.php
= hello
hello.php?a
= world!
after 20 seconds.
--
Edit bug report at http://bugs.php.net/?id=40895edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40895r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40895r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40895r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40895r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40895r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40895r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40895r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40895r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40895r=support
Expected behavior:http://bugs.php.net/fix.php?id=40895r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40895r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40895r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40895r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40895r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40895r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40895r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40895r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40895r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40895r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40895r=mysqlcfg
#40896 [NEW]: hoy
From: crisarana2006 at yahoo dot com
Operating system: mac os
PHP version: 4.4.5
PHP Bug Type: *General Issues
Bug description: hoy
Description:
La secuencia 1820.20 no consiste en todos los dÃgitos.
La secuencia 10002 consiste en todos los dÃgitos. ¡El
wsl de la secuencia! 12 no consiste en todos los
dÃgitos.
Reproduce code:
---
¿? php
¡$strings = arsenal (â1820.20â?, â10002â?, âwsl! 12â?);
foreach ($strings como $testcase) {
si (ctype_digit ($testcase)) {
repetir âla secuencia $testcase consiste en todos los dÃgitos. \
nâ?;
} {
repetir âla secuencia $testcase no consiste en todos los
dÃgitos. \ nâ?;
}
}
?
Expected result:
La secuencia 1820.20 no consiste en todos los dÃgitos. La
secuencia
10002 consiste en todos los dÃgitos. ¡El wsl de la secuencia! 12
no
consiste en todos los dÃgitos.
--
Edit bug report at http://bugs.php.net/?id=40896edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40896r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40896r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40896r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40896r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40896r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40896r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40896r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40896r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40896r=support
Expected behavior:http://bugs.php.net/fix.php?id=40896r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40896r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40896r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40896r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40896r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40896r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40896r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40896r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40896r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40896r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40896r=mysqlcfg
#40896 [Opn-Bgs]: hoy
ID: 40896
Updated by: [EMAIL PROTECTED]
Reported By: crisarana2006 at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: mac os
PHP Version: 4.4.5
New Comment:
Please speak English.
Previous Comments:
[2007-03-22 17:38:08] crisarana2006 at yahoo dot com
Description:
La secuencia 1820.20 no consiste en todos los dÃgitos.
La secuencia 10002 consiste en todos los dÃgitos. ¡El
wsl de la secuencia! 12 no consiste en todos los
dÃgitos.
Reproduce code:
---
¿? php
¡$strings = arsenal (â1820.20â?, â10002â?, âwsl! 12â?);
foreach ($strings como $testcase) {
si (ctype_digit ($testcase)) {
repetir âla secuencia $testcase consiste en todos los
dÃgitos. \ nâ?;
} {
repetir âla secuencia $testcase no consiste en todos los
dÃgitos. \ nâ?;
}
}
?
Expected result:
La secuencia 1820.20 no consiste en todos los dÃgitos. La
secuencia
10002 consiste en todos los dÃgitos. ¡El wsl de la secuencia! 12
no
consiste en todos los dÃgitos.
--
Edit this bug report at http://bugs.php.net/?id=40896edit=1
#40895 [Opn-Bgs]: Problem for ending http_requests with Keep-Alive
ID: 40895
Updated by: [EMAIL PROTECTED]
Reported By: allali at labri dot fr
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: Linux
PHP Version: 5.2.1
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2007-03-22 17:21:16] allali at labri dot fr
Description:
The problem is that I have a script which is called twice by the same
brother using a Http connection with the Keep Alive attibute.
For the first call:
I notify the end of the answer as follow:
===
ignore_user_abort(true);
$msg=toto;
header(Content-Length: .strlen($msg));
echo $msg;
flush();
... some long time stuff here=
===
the browser read the answer and then I ask again for the same page
using the same tcp connection (Keep-alive).
In the second call, the output is blocked until the first call process
is dead. Thus its execution is suspended until the long time stuff is
done. (I see the http request using tcpdump).
If I put the following for the first call:
header(Cache-Control: no-cache, must-revalidate);
header(Expires: Mon, 26 Jul 1997 05:00:00 GMT);
header(Connection: close);
$msg=toto;
header(Content-Length: .strlen($msg));
echo $msg;
flush();
=
then all work fine except that the connection is effectively closed by
the browser and then re-open which implies a great lost of
performances.
Also I did not find any mechanism (bug?) in php to indicate that the
response is done. (like http_close or fclose(STDOUT) // STDOUT doesn't
exists...). Maybe, php is suppose to guess that using the Content-Length
(bug?).
Perhaps it is apache which is waiting for the end of the process or the
closing of the standard process output.
Finally, I think this become critical in AJAX aplications.
Thx
J.A.
Reproduce code:
---
? // hello.php
if (isset($_GET[a])==false){
ignore_user_abort(true);
$msg=hello;
header(Content-Length: .strlen($msg));
if (isset($_GET[close])){
header(Cache-Control: no-cache, must-revalidate);
header(Expires: Mon, 26 Jul 1997 05:00:00 GMT);
header(Connection: close);
}
echo $msg;
flush();
sleep(20);
}
else{
echo world!;
}
?
Expected result:
just call the script twice:
hello.php
= hello
hello.php?a
= world!
immediately
Actual result:
--
just call the script twice:
hello.php
= hello
hello.php?a
= world!
after 20 seconds.
--
Edit this bug report at http://bugs.php.net/?id=40895edit=1
#40897 [NEW]: error_log file not locked
From: david at acz dot org Operating system: Any PHP version: 5.2.1 PHP Bug Type: *General Issues Bug description: error_log file not locked Description: The internal php_log_err function does not lock the output file. This causes long messages to get mixed together. -- Edit bug report at http://bugs.php.net/?id=40897edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40897r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40897r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40897r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40897r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40897r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40897r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40897r=needscript Try newer version:http://bugs.php.net/fix.php?id=40897r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40897r=support Expected behavior:http://bugs.php.net/fix.php?id=40897r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40897r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40897r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40897r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40897r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40897r=dst IIS Stability:http://bugs.php.net/fix.php?id=40897r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40897r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40897r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40897r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40897r=mysqlcfg
#40893 [Fbk-Opn]: PHP reports wrong total and free space for NFS-mounted filesystems on RedHat
ID: 40893
User updated by: andrew at digicol dot de
Reported By: andrew at digicol dot de
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Redhat EL4
PHP Version: 4.4.5
New Comment:
We get the correct sizes with df (I would not have considered posting
the bug report otherwise). We are using df (coreutils) 5.2.1 on RedHat.
The RedHat version is RHEL 4 btw, not 3.
Maybe it is an NFS-related bug that is handled gracefully in df.
Previous Comments:
[2007-03-22 17:19:58] [EMAIL PROTECTED]
From what I can see in df sources, it uses exactly the same logics as
PHP, so I don't really see how it's possible that you get correct values
with df, especially taking into account that the f_frsize is broken in
the same way there.
You might want to look at this RH bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146427
It says that RHEL3 U4 fixes it.
[2007-03-22 15:38:21] andrew at digicol dot de
RedHat Linux:
strace /dot/dc/bin/php/bin/php -r 'echo
number_format(disk_total_space(/mnt)) . \n;'
...
statfs(/mnt, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093458, f_bavail=5093458, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
...
SuSE Linux:
strace php -r 'echo number_format(disk_total_space(/mnt)) . \n;'
...
statfs(/mnt, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093458, f_bavail=5093458, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=32768}) = 0
...
Just in case this helps, df -h seems to invoke the a different system
call (statfs64, both systems are 32-bit, I am not an expert regarding
system calls). They result in the same f_bsize and fr_size values.
Unlike php, df draws the correct conclusions regarding total / free
space on both systems:
RedHat Linux:
strace df -h
...
statfs64(/mnt, 84, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093460, f_bavail=5093460, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
...
SuSE Linux:
strace df -h
...
statfs64(/mnt, 84, {f_type=NFS_SUPER_MAGIC, f_bsize=32768,
f_blocks=9158253, f_bfree=5093460, f_bavail=5093460, f_files=0,
f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=32768}) = 0
...
[2007-03-22 15:21:36] [EMAIL PROTECTED]
If you're still able to reproduce it - try to trace it and figure out
which blocksize is reported by the system and which function is used -
statvfs() or statfs().
[2007-03-22 15:17:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2007-03-22 15:06:32] andrew at digicol dot de
PHP version seems to be irrelevant, but I was forced to choose a
version because of the bug category. I couldn't find the versions I
tried it on (4.3.9, 5.2.0) in the version drop-down.
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/40893
--
Edit this bug report at http://bugs.php.net/?id=40893edit=1
#40090 [Bgs]: Bug in preg_replace concerning UTF-8 characters
ID: 40090
Updated by: [EMAIL PROTECTED]
Reported By: bertrand dot debaenst at gmx dot net
Status: Bogus
Bug Type: PCRE related
Operating System: windows XP
PHP Version: 5CVS-2007-01-10 (snap)
New Comment:
I was looking to this bug report and this is not a bug in PHP nor in
PCRE. You need to activate the UTF-8 mode, by using the //u pattern
modifier (e.g. /\s+/u).
Previous Comments:
[2007-01-10 15:30:00] [EMAIL PROTECTED]
This is PCRE library issue, not PHP.
[2007-01-10 15:16:49] bertrand dot debaenst at gmx dot net
Description:
when replacing an utf-8 string containing the character 'à' (hex: c3a0)
With the function preg_replace, and the pattern '\s', it changes the
second byte of this character.
Using the pattern '\t\f\r\n' which is supposed to be the same as \s it
works perfectly.
I have tried with other utf-8 characters and it seems to work.
Reproduce code:
---
?
$text = utf8_encode(this is a test àt);
echo bin2hex($text).\r\n;
$text1 = preg_replace('([\t\f\r\n])+', , $text);
echo bin2hex($text1).\r\n;
echo $text1.\r\n;;
$text2 = preg_replace('([\s])+', , $text);
echo bin2hex($text2).\r\n;
echo $text2;
?
Expected result:
746869732069732061207465737420c3a074
746869732069732061207465737420c3a074
this is a test #9500;át
746869732069732061207465737420c3a074
this is a test #9500;át
Actual result:
--
746869732069732061207465737420c3a074
746869732069732061207465737420c3a074
this is a test #9500;át
746869732069732061207465737420c32074
this is a test #9500; t
--
Edit this bug report at http://bugs.php.net/?id=40090edit=1
#40871 [Asn]: preg_replace returns blank when the text contains bad UTF-8
ID: 40871 Updated by: [EMAIL PROTECTED] Reported By: ismith at motorola dot com Status: Assigned Bug Type: PCRE related Operating System: Windows Server 2003 SP1 PHP Version: 5.2.1 Assigned To: andrei New Comment: in PHP 6, PHP always passes well-formed utf-8 strings to pcre, because the strings are previously processed by ICU. In PHP 4/5, well.. It's hard to leave up to the user-land app to deal with these kind of complex things, but should we really interfere with string? I dunno.. but my point is that maintaing BC is more important at this time.. Previous Comments: [2007-03-22 00:29:24] [EMAIL PROTECTED] Did you see this: http://us3.php.net/manual/en/function.preg-last-error.php The error is not getting lost. There's just not much we can do about it aside from returning it to the user. [2007-03-21 22:47:02] [EMAIL PROTECTED] Andrei, do you think there is something we can do about it? [2007-03-21 17:45:27] ismith at motorola dot com Further info: I emailed the PCRE maintainer, and he said that since PCRE doesn't do the replacement part, PCRE itself isn't dumping the text. Apparently when PCRE sees bad UTF8, it returns an error code (I believe PCRE_ERROR_BADUTF8). I think the text is getting lost by php_pcre_replace_impl. If pcre_exec returns PCRE_ERROR_NOMATCH, it saves all the unmatched text in the result; but if pcre_exec returns some other error code, it looks to me like it's dumping the result (which matches what I'm seeing). I don't see how PHP can do much else than what it's doing; without a match count back from pcre_exec, it can't process the replacements in any case. My feeling is that PCRE should not return an error code in this case, but work around the bad UTF-8 character, which would be more in keeping with the Unicode standard. I'll discuss this further with the PCRE folks. OTOH, maybe MediaWiki should do UTF-8 cleanup on the string before giving it to PHP. [2007-03-20 20:16:57] [EMAIL PROTECTED] Where do I report this? How do I get it fixed? See http://pcre.org, further details I don't know myself. [2007-03-20 20:03:58] ismith at motorola dot com Tony, thanks for the response... but more info would be good. Where do I report this? How do I get it fixed? 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/40871 -- Edit this bug report at http://bugs.php.net/?id=40871edit=1
#40858 [Asn]: Thread safety issue in GD
ID: 40858 Updated by: [EMAIL PROTECTED] Reported By: scottmacvicar at ntlworld dot com Status: Assigned Bug Type: GD related Operating System: RHEL 4 PHP Version: 5.2.1 Assigned To: pajoye New Comment: yep, having a statically declared mutex would fix the problems we are having. I've a patch identical to yours (http://mega.ist.utl.pt/~ncpl/libgd_mutexes.txt) for a while, but we are still waiting for a win32 implementation to merge the patches (there is another open bug report in the gd bugs db about a similar issue) to definitely fix those nasty TS issues. Previous Comments: [2007-03-21 01:37:18] scottmacvicar at ntlworld dot com Patch is available at http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt Quick explanation: * The mutex is created at module startup and destroyed at module shutdown courtesy of two new helper functions within the libGD code base. * The mutex is no longer destroyed at request shutdown. * Locking is performed prior to checking fontCache to prevent the race condition we're seeing. This can't be merged back into libGD at the moment since it breaks backwards compatibility by assuming a mutex has been allocated, the way to fix this for pthread is fairly easy. #define gdMutexDeclare(x) pthread_mutex_t x #define gdMutexDeclare(x) pthread_mutex_t x becomes #define gdMutexDeclare(x) static pthread_mutex_t x = PTHREAD_MUTEX_INITIALIZER #define gdMutexSetup(x) That would just leave the win32 implementation to deal with via DLLMain, a quick patch to add that would only take a few minutes though I don't have VC6 installed yet. [2007-03-21 00:48:56] [EMAIL PROTECTED] Moving the code to PHP_MINIT fixes the problem for PHP but the threading options of GD doesn't extend itself to this setup since the function to create the mutex can be called more than once in a short period of time. Do you mean for libGD itself used a library in a random project? If yes, a solution is very similar to this one. We have to do it at load time (like DLLMain on windows). Many other libraries (and many related to FT2, with ft2 cache or their own) rely on this solution. We can give it a try, at least. I've got a patch that implements the PHP solution running on our boxes, I can provide it if interested. You can always post it, I still did not get the time to do it, so any help is welcome. [2007-03-21 00:40:40] scottmacvicar at ntlworld dot com Moving the code to PHP_MINIT fixes the problem for PHP but the threading options of GD doesn't extend itself to this setup since the function to create the mutex can be called more than once in a short period of time. This small race condition could be fixed by using pthread_once to ensure the mutexes are allocated only once but I'm unsure of the Win32 equivalent. I've got a patch that implements the PHP solution running on our boxes, I can provide it if interested. [2007-03-19 19:27:31] [EMAIL PROTECTED] Did we not put it inside in the latest version of the last patch? I do not have the code at hand but as far as I remember Nuno updated it. I will check again tonight. [2007-03-19 19:24:54] [EMAIL PROTECTED] The first problem looks weird. It defeats the whole purpose of the mutex. The !=NULL check is out of the mutex protected block. 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/40858 -- Edit this bug report at http://bugs.php.net/?id=40858edit=1
#40806 [Asn-Bgs]: session id gets over-written by other server's cookie
ID: 40806 Updated by: [EMAIL PROTECTED] Reported By: john at albin dot net -Status: Assigned +Status: Bogus Bug Type:Session related PHP Version: 5.2.1 Assigned To: iliaa New Comment: If the browser is compliant with the spec the more specific cookies are sent first and PHP prevent their overwriting by less specific cookies. Previous Comments: [2007-03-21 05:56:45] John at Albin dot Net This will also affect session cookies from the same server, but with different paths. e.g. Given a request for http://example.com/path1, a domain=.example.com; path=/ session cookie will over-write the correct domain=.example.com; path=/path1 session cookie. [2007-03-14 19:11:51] john at albin dot net Description: Here's a not-so-unusual situation: If a user goes to a PHP-based website with enabled sessions at http:// example.com, by default PHP sets a cookie named PHPSESSID for .example.com. If that user then goes to a seperate website at http:// other.example.com, PHP sets a cookie named PHPSESSID for .other.example.com. From the cookie spec: When sending cookies to a server, all cookies with a more specific path mapping should be sent before cookies with less specific path mappings. For example, a cookie name1=foo with a path mapping of / should be sent after a cookie name1=foo2 with a path mapping of / bar if they are both to be sent. Even though both cookies are submitted by the browser back to the other.example.com website, PHP clobbers the value of the more-specific cookie with the less-specific cookie that follows. So there's no way that the PHP code could ever get the correct session id. Reproduce code: --- Go to http://example.com and let PHP set a default session cookie. Go to http://other.example.com and let PHP set a default session cookie. On the other.example.com website run: ?php session_start(); $value = $_COOKIE['PHPSESSID'] ? Expected result: To get the session_id from the .other.example.com cookie. Actual result: -- You get the session_id from the .example.com cookie. -- Edit this bug report at http://bugs.php.net/?id=40806edit=1
#40858 [Asn]: Thread safety issue in GD
ID: 40858 User updated by: scottmacvicar at ntlworld dot com Reported By: scottmacvicar at ntlworld dot com Status: Assigned Bug Type: GD related Operating System: RHEL 4 PHP Version: 5.2.1 Assigned To: pajoye New Comment: I have some time to spare over the weekend and a copy of VC6 installed now so I'll have a go at the win32 implementation. Regarding the patch to the bundled GD library and the php wrapper, does it look reasonable? We've been running it for the past 2 days now without issue on a production server. I'd rather see something put into 5.2.2 and then fix libGD. Previous Comments: [2007-03-22 23:15:13] [EMAIL PROTECTED] yep, having a statically declared mutex would fix the problems we are having. I've a patch identical to yours (http://mega.ist.utl.pt/~ncpl/libgd_mutexes.txt) for a while, but we are still waiting for a win32 implementation to merge the patches (there is another open bug report in the gd bugs db about a similar issue) to definitely fix those nasty TS issues. [2007-03-21 01:37:18] scottmacvicar at ntlworld dot com Patch is available at http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt Quick explanation: * The mutex is created at module startup and destroyed at module shutdown courtesy of two new helper functions within the libGD code base. * The mutex is no longer destroyed at request shutdown. * Locking is performed prior to checking fontCache to prevent the race condition we're seeing. This can't be merged back into libGD at the moment since it breaks backwards compatibility by assuming a mutex has been allocated, the way to fix this for pthread is fairly easy. #define gdMutexDeclare(x) pthread_mutex_t x #define gdMutexDeclare(x) pthread_mutex_t x becomes #define gdMutexDeclare(x) static pthread_mutex_t x = PTHREAD_MUTEX_INITIALIZER #define gdMutexSetup(x) That would just leave the win32 implementation to deal with via DLLMain, a quick patch to add that would only take a few minutes though I don't have VC6 installed yet. [2007-03-21 00:48:56] [EMAIL PROTECTED] Moving the code to PHP_MINIT fixes the problem for PHP but the threading options of GD doesn't extend itself to this setup since the function to create the mutex can be called more than once in a short period of time. Do you mean for libGD itself used a library in a random project? If yes, a solution is very similar to this one. We have to do it at load time (like DLLMain on windows). Many other libraries (and many related to FT2, with ft2 cache or their own) rely on this solution. We can give it a try, at least. I've got a patch that implements the PHP solution running on our boxes, I can provide it if interested. You can always post it, I still did not get the time to do it, so any help is welcome. [2007-03-21 00:40:40] scottmacvicar at ntlworld dot com Moving the code to PHP_MINIT fixes the problem for PHP but the threading options of GD doesn't extend itself to this setup since the function to create the mutex can be called more than once in a short period of time. This small race condition could be fixed by using pthread_once to ensure the mutexes are allocated only once but I'm unsure of the Win32 equivalent. I've got a patch that implements the PHP solution running on our boxes, I can provide it if interested. [2007-03-19 19:27:31] [EMAIL PROTECTED] Did we not put it inside in the latest version of the last patch? I do not have the code at hand but as far as I remember Nuno updated it. I will check again tonight. 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/40858 -- Edit this bug report at http://bugs.php.net/?id=40858edit=1
#40898 [NEW]: MySQLi segfaults during module initialization
From: demiurg at gmail dot com Operating system: Linux i686 PHP version: 6CVS-2007-03-23 (CVS) PHP Bug Type: MySQLi related Bug description: MySQLi segfaults during module initialization Description: Please, delete the extra STANDARD_MODULE_HEADER line at ext/mysqli/mysqli.c:442 Reproduce code: --- # sapi/cli/php -m Segmentation fault (gdb) bt #0 0xb68474c3 in strlen () from /lib/libc.so.6 #1 0x083a0546 in zend_register_module_ex (module=0x85e19c0) at Zend/zend_API.c:1923 #2 0x0834ba8c in php_register_extensions (ptr=0x85fe7a4, count=54) at main/main.c:1531 #3 0x0842689b in php_register_internal_extensions () at main/internal_functions_cli.c:149 #4 0x0834ca4b in php_module_startup (sf=0x85fe600, additional_modules=0x0, num_additional_modules=0) at main/main.c:1749 #5 0x08423dbd in php_cli_startup (sapi_module=0x85fe600) at sapi/cli/php_cli.c:341 #6 0x0842454c in main (argc=2, argv=0xbfca8f14) at sapi/cli/php_cli.c:719 -- Edit bug report at http://bugs.php.net/?id=40898edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40898r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40898r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40898r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40898r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40898r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40898r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40898r=needscript Try newer version:http://bugs.php.net/fix.php?id=40898r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40898r=support Expected behavior:http://bugs.php.net/fix.php?id=40898r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40898r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40898r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40898r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40898r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40898r=dst IIS Stability:http://bugs.php.net/fix.php?id=40898r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40898r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40898r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40898r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40898r=mysqlcfg
#40858 [Asn]: Thread safety issue in GD
ID: 40858 Updated by: [EMAIL PROTECTED] Reported By: scottmacvicar at ntlworld dot com Status: Assigned Bug Type: GD related Operating System: RHEL 4 PHP Version: 5.2.1 Assigned To: pajoye New Comment: Hi Scott, Nuno, Regarding the patch to the bundled GD library and the php wrapper, does it look reasonable? We've been running it for the past 2 days now without issue on a production server. I'd rather see something put into 5.2.2 Yes, the patch for php (and unix) looks good. I will apply it during the weekend as well (or Nuno, you can do it if you have the time before). For the windows version, that's a good news, thanks to take the time to work on it. Previous Comments: [2007-03-23 00:31:35] scottmacvicar at ntlworld dot com I have some time to spare over the weekend and a copy of VC6 installed now so I'll have a go at the win32 implementation. Regarding the patch to the bundled GD library and the php wrapper, does it look reasonable? We've been running it for the past 2 days now without issue on a production server. I'd rather see something put into 5.2.2 and then fix libGD. [2007-03-22 23:15:13] [EMAIL PROTECTED] yep, having a statically declared mutex would fix the problems we are having. I've a patch identical to yours (http://mega.ist.utl.pt/~ncpl/libgd_mutexes.txt) for a while, but we are still waiting for a win32 implementation to merge the patches (there is another open bug report in the gd bugs db about a similar issue) to definitely fix those nasty TS issues. [2007-03-21 01:37:18] scottmacvicar at ntlworld dot com Patch is available at http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt Quick explanation: * The mutex is created at module startup and destroyed at module shutdown courtesy of two new helper functions within the libGD code base. * The mutex is no longer destroyed at request shutdown. * Locking is performed prior to checking fontCache to prevent the race condition we're seeing. This can't be merged back into libGD at the moment since it breaks backwards compatibility by assuming a mutex has been allocated, the way to fix this for pthread is fairly easy. #define gdMutexDeclare(x) pthread_mutex_t x #define gdMutexDeclare(x) pthread_mutex_t x becomes #define gdMutexDeclare(x) static pthread_mutex_t x = PTHREAD_MUTEX_INITIALIZER #define gdMutexSetup(x) That would just leave the win32 implementation to deal with via DLLMain, a quick patch to add that would only take a few minutes though I don't have VC6 installed yet. [2007-03-21 00:48:56] [EMAIL PROTECTED] Moving the code to PHP_MINIT fixes the problem for PHP but the threading options of GD doesn't extend itself to this setup since the function to create the mutex can be called more than once in a short period of time. Do you mean for libGD itself used a library in a random project? If yes, a solution is very similar to this one. We have to do it at load time (like DLLMain on windows). Many other libraries (and many related to FT2, with ft2 cache or their own) rely on this solution. We can give it a try, at least. I've got a patch that implements the PHP solution running on our boxes, I can provide it if interested. You can always post it, I still did not get the time to do it, so any help is welcome. [2007-03-21 00:40:40] scottmacvicar at ntlworld dot com Moving the code to PHP_MINIT fixes the problem for PHP but the threading options of GD doesn't extend itself to this setup since the function to create the mutex can be called more than once in a short period of time. This small race condition could be fixed by using pthread_once to ensure the mutexes are allocated only once but I'm unsure of the Win32 equivalent. I've got a patch that implements the PHP solution running on our boxes, I can provide it if interested. 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/40858 -- Edit this bug report at http://bugs.php.net/?id=40858edit=1
