Bug #62648 [Com]: similar_text() returns wrong values
Edit report at https://bugs.php.net/bug.php?id=62648&edit=1
ID: 62648
Comment by: carloschilazo at gmail dot com
Reported by:normadize at gmail dot com
Summary:similar_text() returns wrong values
Status: Open
Type: Bug
Package:Strings related
Operating System: Linux, Win32
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
the only thing that I'd want to clear out first about this, is the performance
of
your algorithm vs the built-in function.
Could you please provide the test case you are using to measure this?
Thanks!
Previous Comments:
[2012-07-29 05:48:14] normadize at gmail dot com
Note that besides giving different results when swapping arguments, it gives
wrong results sometimes completely. Here's an example:
Gives 34,32 instead of 35,35.
Longest common substring is "studofironoxidedextrintinbcdtudgafd" which is 35
chars long.
I have written a small custom PHP extension that I compile and load in all my
PHP deployments for speed because a PHP implementation of the longest common
substring algorithm in PHP is painfully slow. My extension is based on suffix
trees rather than recursive calls, which is generally faster for short to
moderately long strings.
Isn't any dev interested in fixing this very useful function? It's been such a
long time ...
I can post my extension code and will attempt to patch the original
similar_text() too.
[2012-07-24 06:17:33] normadize at gmail dot com
Description:
similar_text() returns wrong values, see below for reproducible error.
This is actually a very old bug ... would be nice if someone finally fixed it.
Test script:
---
echo similar_text("test","wert");
echo "|";
echo similar_text("wert","test");
Expected result:
2|2
Actual result:
--
1|2
--
Edit this bug report at https://bugs.php.net/bug.php?id=62648&edit=1
Bug #62171 [Com]: "Nesting level too deep - recursive dependency?" in case of ===
Edit report at https://bugs.php.net/bug.php?id=62171&edit=1 ID: 62171 Comment by: carloschilazo at gmail dot com Reported by:ray dot burgemeestre at gmail dot com Summary:"Nesting level too deep - recursive dependency?" in case of === Status: Open Type: Bug Package:*Programming Data Structures Operating System: linux PHP Version:5.4.3 Block user comment: N Private report: N New Comment: I think the problem is your test script: you are passing the value of $a by reference, and to invoke the value then it calls itself. remove the & and it works Previous Comments: [2012-05-28 15:56:06] shiranai7 at hotmail dot com I can confirm this on Windows. I also tried more cases: For arrays: $a = array(); $a[0] = &$a; For objects: $a = new stdClass; $a->b = &$a; Results for comparisons of $a, $b TypePHP OperatorResult - arrays 4.4.5 == fatal arrays 4.4.5 === fatal objects 4.4.5 == fatal objects 4.4.5 === fatal arrays 5.2.6 == fatal arrays 5.2.6 === fatal objects 5.2.6 == true objects 5.2.6 === true arrays 5.3.5 == fatal arrays 5.3.5 === fatal objects 5.3.5 == true objects 5.3.5 === true arrays 5.4.3 == fatal arrays 5.4.3 === fatal objects 5.4.3 == true objects 5.4.3 === true So this was fixed (either intentionally or along with general changes to object handling) in PHP 5 for objects but not for arrays. [2012-05-27 14:40:33] ray dot burgemeestre at gmail dot com Description: Is it expected behaviour that === can trigger a Nesting level too deep error? Test script: --- Expected result: I would expect $a === $a to return true. Actual result: -- $ php test.php PHP Fatal error: Nesting level too deep - recursive dependency? in /srv/www/htdocs/test.php on line 3 Fatal error: Nesting level too deep - recursive dependency? in /srv/www/htdocs/test.php on line 3 $ php -v PHP 5.4.3 (cli) (built: May 26 2012 22:29:08) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies -- Edit this bug report at https://bugs.php.net/bug.php?id=62171&edit=1
Bug #62004 [Com]: SplFileObject: fgets after seek returns wrong line
Edit report at https://bugs.php.net/bug.php?id=62004&edit=1
ID: 62004
Comment by: carloschilazo at gmail dot com
Reported by:don dot binda at verizon dot net
Summary:SplFileObject: fgets after seek returns wrong line
Status: Open
Type: Bug
Package:SPL related
Operating System: Windows Server 2003
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Based on documentation, it says that fgets Returns:
Returns a string containing the NEXT line from the file
wouldn't that explain?
Previous Comments:
[2012-05-17 14:35:16] don dot binda at verizon dot net
Fixing version
[2012-05-11 13:59:04] don dot binda at verizon dot net
Description:
This is occurring in 5.4.0, although 5.4.x isn't an option under version.
Appears to be related to (or same as) 46569:
Calling fgets() after seek() to any non-zero line returns one line later than
expected. seek(0) works fine and calling current() instead of fgets() also
works correctly.
Test script:
---
Source file (temp.txt):
Line 1
Line 2
Line 3
Line 4
Code:
$f = new SplFileObject('temp.txt');
$f->seek(0);
echo $f->fgets();
$f->seek(1);
echo $f->fgets();
$f->seek(2);
echo $f->fgets();
Expected result:
Line 1
Line 2
Line 3
Actual result:
--
Line 1
Line 3
Line 4
--
Edit this bug report at https://bugs.php.net/bug.php?id=62004&edit=1
Bug #61156 [Com]: Segfault when using get_defined_constants(true)
Edit report at https://bugs.php.net/bug.php?id=61156&edit=1 ID: 61156 Comment by: carloschilazo at gmail dot com Reported by:damien at overeem dot org Summary:Segfault when using get_defined_constants(true) Status: Open Type: Bug Package:Reproducible crash Operating System: openSUSE 11.4 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Could not reproduce on 5.3.10, this can be closed Previous Comments: [2012-02-21 16:08:28] damien at overeem dot org Description: ATTN: This is a bug in php verison 5.3.5 !! I do realize that this is about an earlier version, but I have no available environments on which i could simply upgrade. So consider this bug report as a notification. It can be closed if not considered a valid report. We resolved our issue by circumventing use of the categorization of get_defined_constants. The function get_defined_constants(true) causes a client segfault ([Tue Feb 21 16:18:24 2012] [notice] child pid 12564 exit signal Segmentation fault (11)) There are some references to this issue occurring ie. #51788. In that particular case however, the issue seemed to have been caused by suhosin. My installation is running native php2 engine v2.3.0. When using get_defined_constants() (without the categorization parameter) there is no problem. Further information: OS: openSUSE 11.4 Kernel: 2.6.37.6-0.11-default Apache version: 2.2.17 ( API Version 20051115) PHP Version: 5.3.5 Loaded modules: core prefork http_core mod_so mod_unique_id mod_actions mod_alias mod_auth_basic mod_authn_file mod_authz_host mod_authz_groupfile mod_authz_default mod_authz_user mod_authn_dbm mod_autoindex mod_cgi mod_dir mod_env mod_expires mod_include mod_log_config mod_mime mod_negotiation mod_setenvif mod_ssl mod_status mod_suexec mod_userdir mod_vhost_alias mod_rewrite mod_php5 mod_info mod_dav mod_deflate mod_proxy mod_proxy_http Test script: --- Expected result: No output, no error logging. Actual result: -- Output: Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data. Apache error log: [Tue Feb 21 16:18:24 2012] [notice] child pid 12564 exit signal Segmentation fault (11) -- Edit this bug report at https://bugs.php.net/bug.php?id=61156&edit=1
Bug #61135 [Com]: gregoriantojd() returns incorrect date for some dates
Edit report at https://bugs.php.net/bug.php?id=61135&edit=1 ID: 61135 Comment by: carloschilazo at gmail dot com Reported by:t dot m dot guymer at thomasguymer dot co dot uk Summary:gregoriantojd() returns incorrect date for some dates Status: Open Type: Bug Package:*Calendar problems Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Confirmed, working on a fix right now, will upload it shortly Previous Comments: [2012-02-18 17:26:41] t dot m dot guymer at thomasguymer dot co dot uk Description: I am using gregoriantojd() to return the Julian date for some months in the year 2011. It gives the correct answer for 10 of the months, but August and September just get returned as "0". Test script: --- echo "The 1st of January 2011 is " . gregoriantojd(01, 01, 2011) . PHP_EOL; echo "The 1st of February 2011 is " . gregoriantojd(02, 01, 2011) . PHP_EOL; echo "The 1st of March 2011 is " . gregoriantojd(03, 01, 2011) . PHP_EOL; echo "The 1st of April 2011 is " . gregoriantojd(04, 01, 2011) . PHP_EOL; echo "The 1st of May 2011 is " . gregoriantojd(05, 01, 2011) . PHP_EOL; echo "The 1st of June 2011 is " . gregoriantojd(06, 01, 2011) . PHP_EOL; echo "The 1st of July 2011 is " . gregoriantojd(07, 01, 2011) . PHP_EOL; echo "The 1st of August 2011 is " . gregoriantojd(08, 01, 2011) . PHP_EOL; echo "The 1st of September 2011 is " . gregoriantojd(09, 01, 2011) . PHP_EOL; echo "The 1st of October 2011 is " . gregoriantojd(10, 01, 2011) . PHP_EOL; echo "The 1st of November 2011 is " . gregoriantojd(11, 01, 2011) . PHP_EOL; echo "The 1st of December 2011 is " . gregoriantojd(12, 01, 2011) . PHP_EOL; Expected result: The 1st of January 2011 is 2455563 The 1st of February 2011 is 2455594 The 1st of March 2011 is 2455622 The 1st of April 2011 is 2455653 The 1st of May 2011 is 2455683 The 1st of June 2011 is 2455714 The 1st of July 2011 is 2455744 The 1st of August 2011 is 2455775 The 1st of September 2011 is 2455805 The 1st of October 2011 is 2455836 The 1st of November 2011 is 2455867 The 1st of December 2011 is 2455897 Actual result: -- The 1st of January 2011 is 2455563 The 1st of February 2011 is 2455594 The 1st of March 2011 is 2455622 The 1st of April 2011 is 2455653 The 1st of May 2011 is 2455683 The 1st of June 2011 is 2455714 The 1st of July 2011 is 2455744 The 1st of August 2011 is 0 The 1st of September 2011 is 0 The 1st of October 2011 is 2455836 The 1st of November 2011 is 2455867 The 1st of December 2011 is 2455897 -- Edit this bug report at https://bugs.php.net/bug.php?id=61135&edit=1
Bug #61013 [Com]: Php logging to a file now defaults to UTC?
Edit report at https://bugs.php.net/bug.php?id=61013&edit=1 ID: 61013 Comment by: carloschilazo at gmail dot com Reported by:mgoebel at emich dot edu Summary:Php logging to a file now defaults to UTC? Status: Open Type: Bug Package:Date/time related Operating System: Solaris 10, and SLES 11.1 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: The issue was that the local time flag was set to 0, with attached fix the local time flag is now fixed and the log string now contains the local time instead of UTC Previous Comments: [2012-02-08 16:20:36] mgoebel at emich dot edu Description: I have a pretty generic setup on both Solaris 10 and SLES 11.1, and both setups have "date.timezone = America/Detroit" in their php.ini files. After I upgraded from 5.3.8 to 5.3.10 all of the log entries are now using UTC instead of the localy defined timezone. [08-Feb-2012 09:59:38] PHP Deprecated: ... [08-Feb-2012 09:59:38] PHP Deprecated: ... [08-Feb-2012 15:00:15 UTC] PHP Deprecated: ... [08-Feb-2012 15:00:15 UTC] PHP Deprecated: ... [08-Feb-2012 15:00:37 UTC] PHP Warning: ... All of webpages seem to be handing date/times correctly, just the logging seems to be having issues. -- Edit this bug report at https://bugs.php.net/bug.php?id=61013&edit=1
Bug #61014 [Com]: Memory leak on unserialize for certain nested objects
Edit report at https://bugs.php.net/bug.php?id=61014&edit=1 ID: 61014 Comment by: carloschilazo at gmail dot com Reported by:npm at nuestrared dot com Summary:Memory leak on unserialize for certain nested objects Status: Open Type: Bug Package:Performance problem Operating System: Debian Linux PHP Version:5.4SVN-2012-02-08 (snap) Block user comment: N Private report: N New Comment: I'm not sure the problem is on the unserialize function; I saved the value of $str (after gzuncompress/base64_decode) (so I got the original serialized string, and hardcoded it on the script) Then ran the script and got consistent memory usage... Previous Comments: [2012-02-08 16:24:02] npm at nuestrared dot com Description: Unserializing certain objects on a loop, incurs in increased memory consumption even when the garbage collector is enables and gc_collect_cycles() is called after each iteration. For the test script there is an increase of almost 5MB, after 100 runs, it doesn't happen with every object, but it does with the one on the test. The increase is not with every iteration but every couple of iterations, until it reaches a maximum, in this case the 4980736 bytes. This report is related to bug #60937, I had no reply on my comments. Thanks, Test script: --- The test script can be found at: http://dl.dropbox.com/u/7170408/unserialize_memleak.php Expected result: Consistent memory usage. Actual result: -- The output of the script: Iteration 0 Start Mem 786432 Cicle Mem 3145728 Diff 2359296 Iteration 1 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 2 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 3 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 4 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 5 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 6 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 7 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 8 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 9 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 10 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 11 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 12 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 13 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 14 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 15 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 16 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 17 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 18 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 19 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 20 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 21 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 22 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 23 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 24 Start Mem 786432 Cicle Mem 5505024 Diff 4718592 Iteration 25 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 26 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 27 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 28 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 29 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 30 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 31 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 32 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 33 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 34 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 35 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 36 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 37 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 38 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 39 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 40 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 41 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 42 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 43 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 44 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 45 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 46 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 47 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 48 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 49 Start Mem 786432 Cicle Mem 5767168 Diff 4980736 Iteration 50
Bug #60997 [Com]: getopt() parses optional values incorrectly
Edit report at https://bugs.php.net/bug.php?id=60997&edit=1
ID: 60997
Comment by: carloschilazo at gmail dot com
Reported by:eric at wepay dot com
Summary:getopt() parses optional values incorrectly
Status: Open
Type: Bug
Package:CGI/CLI related
Operating System: Linux CentOS
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Documentation also states:
Note: Optional values do not accept " " (space) as a separator.
Previous Comments:
[2012-02-06 23:51:51] eric at wepay dot com
Description:
If a CLI argument is passed with leading whitespace, the value is not picked up
by
getopt() if specified as an optional value (with two colons). This is contrary
to
the documentation, which states, "Option values are the first argument after
the
string. It does not matter if a value has leading white space or not."
Test script:
---
$ ./test.php -v2 asdf # behaves as expected
$ ./test.php -v=2 asdf # behaves as expected
$ ./test.php -v 2 asdf # problem case, shown in actual result
Expected result:
array(1) {
["v"]=>
bool(false)
}
array(1) {
["v"]=>
string(1) "2"
}
array(1) {
["v"]=>
string(1) "2"
}
Actual result:
--
array(1) {
["v"]=>
bool(false)
}
array(1) {
["v"]=>
string(1) "2"
}
array(1) {
["v"]=>
bool(false)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60997&edit=1
Bug #60960 [Com]: Wrong number of days.
Edit report at https://bugs.php.net/bug.php?id=60960&edit=1
ID: 60960
Comment by: carloschilazo at gmail dot com
Reported by:robertosuursoo at yahoo dot com dot br
Summary:Wrong number of days.
Status: Open
Type: Bug
Package:Date/time related
Operating System: Ubuntu 11.04 64bits
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I couldnt reproduce the problem, I get a result of 1 on:
$a = new DateTime('2012-10-21');
$b = new DateTime('2012-10-22');
$interval = $a->diff($b);
Tested Ubuntu 11 64 bits also
Previous Comments:
[2012-02-02 19:48:53] robertosuursoo at yahoo dot com dot br
Description:
The diff function is calculating the wrong number of days.
PHP 5.3.5-1ubuntu7.4 with Suhosin-Patch (cli) (built: Dec 13 2011 18:30:11)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Test script:
---
TEST
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
diff($b);
?>
$interval->days:days?>
Expected result:
$interval->days:3
$interval->days:2
$interval->days:1
Actual result:
--
$interval->days:3
$interval->days:2
$interval->days:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60960&edit=1
Bug #60933 [Com]: Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6
Edit report at https://bugs.php.net/bug.php?id=60933&edit=1
ID: 60933
Comment by: carloschilazo at gmail dot com
Reported by:m...@php.net
Summary:Testing asort with SORT_LOCALE_STRING fails on Mac
OS X 10.6
Status: Open
Type: Bug
Package:Arrays related
Operating System: Mac OS X 10.6
PHP Version:5.4SVN-2012-01-30 (SVN)
Block user comment: N
Private report: N
New Comment:
I think its not related to MAC OSX, test failed php5.4-201202011630 ubuntu 11.10
Previous Comments:
[2012-02-01 16:32:54] ras...@php.net
Bug 41758 is a won't fix simply because it is against PHP6 and we aren't fixing
bugs in that dead branch at this point. This also a different issue since this
one appears to be OSX-specific. This same test passes nicely on various
versions
of Debian and Ubuntu Linux.
[2012-02-01 13:03:39] f...@php.net
Works on FreeBSD 8.2-RELEASE with snap php5.4-201202011030
PASS Sort with SORT_LOCALE_STRING [ext/standard/tests/array/locale_sort.phpt]
[2012-02-01 03:58:53] carloschilazo at gmail dot com
I think this goes waaay back to: 41758
And bug 41758 is in status Won't fix, I couldn't find why.
Is there a reason behind this?
Thanks
[2012-01-30 13:50:47] m...@php.net
Description:
The test ext/standard/tests/array/locale_sort.phpt fails.
"Ãle-du-Prince-Ãdouard"
is sorted to the end of the array, instead of the expected 3rd position.
Test script:
---
"Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Ãcosse",
"ON" => "Ontario",
"PE" => "Ãle-du-Prince-Ãdouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table, SORT_LOCALE_STRING);
var_dump($table);
Expected result:
array(13) {
["AB"]=>
string(7) "Alberta"
["BC"]=>
string(20) "Colombie-Britannique"
["PE"]=>
string(21) "Ãle-du-Prince-Ãdouard"
["MB"]=>
string(8) "Manitoba"
["NB"]=>
string(17) "Nouveau-Brunswick"
["NS"]=>
string(15) "Nouvelle-Ãcosse"
["NU"]=>
string(7) "Nunavut"
["ON"]=>
string(7) "Ontario"
["QC"]=>
st
Bug #60933 [Com]: Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6
Edit report at https://bugs.php.net/bug.php?id=60933&edit=1
ID: 60933
Comment by: carloschilazo at gmail dot com
Reported by:m...@php.net
Summary:Testing asort with SORT_LOCALE_STRING fails on Mac
OS X 10.6
Status: Open
Type: Bug
Package:Arrays related
Operating System: Mac OS X 10.6
PHP Version:5.4SVN-2012-01-30 (SVN)
Block user comment: N
Private report: N
New Comment:
I think this goes waaay back to: 41758
And bug 41758 is in status Won't fix, I couldn't find why.
Is there a reason behind this?
Thanks
Previous Comments:
[2012-01-30 13:50:47] m...@php.net
Description:
The test ext/standard/tests/array/locale_sort.phpt fails.
"Ãle-du-Prince-Ãdouard"
is sorted to the end of the array, instead of the expected 3rd position.
Test script:
---
"Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Ãcosse",
"ON" => "Ontario",
"PE" => "Ãle-du-Prince-Ãdouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table, SORT_LOCALE_STRING);
var_dump($table);
Expected result:
array(13) {
["AB"]=>
string(7) "Alberta"
["BC"]=>
string(20) "Colombie-Britannique"
["PE"]=>
string(21) "Ãle-du-Prince-Ãdouard"
["MB"]=>
string(8) "Manitoba"
["NB"]=>
string(17) "Nouveau-Brunswick"
["NS"]=>
string(15) "Nouvelle-Ãcosse"
["NU"]=>
string(7) "Nunavut"
["ON"]=>
string(7) "Ontario"
["QC"]=>
string(6) "Québec"
["SK"]=>
string(12) "Saskatchewan"
["NL"]=>
string(23) "Terre-Neuve-et-Labrador"
["YT"]=>
string(19) "Territoire du Yukon"
["NT"]=>
string(25) "Territoires du Nord-Ouest"
Actual result:
--
array(13) {
Req #60926 [Com]: LIFO/FIFO iterator modes for priority queues
Edit report at https://bugs.php.net/bug.php?id=60926&edit=1
ID: 60926
Comment by: carloschilazo at gmail dot com
Reported by:franssen dot roland at gmail dot com
Summary:LIFO/FIFO iterator modes for priority queues
Status: Open
Type: Feature/Change Request
Package:SPL related
Operating System: Ubuntu
PHP Version:5.4.0RC6
Block user comment: N
Private report: N
New Comment:
I believe this goes against the definition of a priority queue, if you insert
them
with the same priority then it really does not matter which one comes first...
I understand what you are asking, but if you need them like that then you could
maybe use another data structure or a mixture, or user different priorities..
Previous Comments:
[2012-01-29 19:31:07] franssen dot roland at gmail dot com
Description:
PHP version is actually PHP5.4RC3
It would be nice to be able to maintain the input order in a SPL priority queue
when multiple values share the same priority.
E.g. FIFO and LIFO
The current "mode" is neither one of these. I guess this is best
peformance-wise but sometimes you want to be explicitly, for instance when
registering event listeners; you expect them to run in order.
Test script:
---
insert('a', 100);
$queue->insert('b', 100);
$queue->insert('c', 110);
$queue->insert('d', 90);
foreach($queue as $element) {
var_dump($element);
echo '';
}
echo '';
$queue2 = new \SplPriorityQueue;
$queue2->insert('a', 100);
$queue2->insert('b', 100);
foreach($queue2 as $element) {
var_dump($element);
echo '';
}
Expected result:
string(1) "c"
string(1) "a"
string(1) "b"
string(1) "d"
string(1) "a"
string(1) "b"
Actual result:
--
string(1) "c"
string(1) "b"
string(1) "a"
string(1) "d"
string(1) "a"
string(1) "b"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60926&edit=1
Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header
Edit report at https://bugs.php.net/bug.php?id=60887&edit=1
ID: 60887
Comment by: carloschilazo at gmail dot com
Reported by:mail at tomsommer dot dk
Summary:SoapClient ignores user_agent option and sends no
User-Agent header
Status: Open
Type: Bug
Package:SOAP related
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
After yawk@irc replicated the issue, the problem is that the WSDL request is
the
one that is not being sent with the user-agent header set.
Subsequent requests are.
Pending to determine if WSDL request should have user-agent set
(replication with screenshots: http://chilldata.com/dev/soapbug/)
Email will be sent to internals mailing list
Previous Comments:
[2012-01-28 19:16:04] carloschilazo at gmail dot com
Checked it with "User-Agent" and the behavior is the same with and without the
"-"
Better to be RFC compliant (RFC 2616) and add the '-;, I'll upload the patch
again.
Thanks!
----
[2012-01-28 17:41:14] carloschilazo at gmail dot com
This is what I now get after running your script with my patch
Array
(
[DOCUMENT_ROOT] => /home/chilld/public_html
[GATEWAY_INTERFACE] => CGI/1.1
[HTTP_CONNECTION] => close
[HTTP_HOST] => pfdn.local.chilldata.com
[HTTP_USER_AGENT] => foo
[PATH] => /bin:/usr/bin
[QUERY_STRING] => check=1
[REDIRECT_STATUS] => 200
[REMOTE_ADDR] => 189.253.78.75
[REMOTE_PORT] => 20615
[REQUEST_METHOD] => GET
[REQUEST_URI] => /dev/soap.php?check=1
[SCRIPT_FILENAME] => /home/chilld/public_html/dev/soap.php
[SCRIPT_NAME] => /dev/soap.php
[SERVER_ADDR] => 10.34.11.56
[SERVER_ADMIN] => webmas...@chilldata.com
[SERVER_NAME] => www.chilldata.com
[SERVER_PORT] => 80
[SERVER_PROTOCOL] => HTTP/1.1
[SERVER_SIGNATURE] =>
[SERVER_SOFTWARE] => Apache
[UNIQUE_ID] => TyOIZK3Hp1AAADUKGtYL
[PHP_SELF] => /dev/soap.php
[REQUEST_TIME] => 1327728740
[argv] => Array
(
[0] => check=1
)
[argc] => 1
)
and if i change to see the $_SERVER['HTTP_USER_AGENT'] variable I get also foo
[2012-01-28 12:31:41] mail at tomsommer dot dk
Regarding your patch, I believe the header is "User-Agent", not "User Agent" :)
[2012-01-28 09:03:56] carloschilazo at gmail dot com
Oooh sorry, my bad; yeah you were right;
I've posted a fix, I already tested it with no problem, waiting for someone to
comment or commit.
[2012-01-27 10:45:04] mail at tomsommer dot dk
I've tested it on several machines.
It's not a matter of stripping the header, since stream_context works.
My test script:
http://example.com/soap.php?check=1',
array('user_agent' => 'foo'));
}
?>
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
https://bugs.php.net/bug.php?id=60887
--
Edit this bug report at https://bugs.php.net/bug.php?id=60887&edit=1
Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header
Edit report at https://bugs.php.net/bug.php?id=60887&edit=1
ID: 60887
Comment by: carloschilazo at gmail dot com
Reported by:mail at tomsommer dot dk
Summary:SoapClient ignores user_agent option and sends no
User-Agent header
Status: Open
Type: Bug
Package:SOAP related
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Checked it with "User-Agent" and the behavior is the same with and without the
"-"
Better to be RFC compliant (RFC 2616) and add the '-;, I'll upload the patch
again.
Thanks!
Previous Comments:
----
[2012-01-28 17:41:14] carloschilazo at gmail dot com
This is what I now get after running your script with my patch
Array
(
[DOCUMENT_ROOT] => /home/chilld/public_html
[GATEWAY_INTERFACE] => CGI/1.1
[HTTP_CONNECTION] => close
[HTTP_HOST] => pfdn.local.chilldata.com
[HTTP_USER_AGENT] => foo
[PATH] => /bin:/usr/bin
[QUERY_STRING] => check=1
[REDIRECT_STATUS] => 200
[REMOTE_ADDR] => 189.253.78.75
[REMOTE_PORT] => 20615
[REQUEST_METHOD] => GET
[REQUEST_URI] => /dev/soap.php?check=1
[SCRIPT_FILENAME] => /home/chilld/public_html/dev/soap.php
[SCRIPT_NAME] => /dev/soap.php
[SERVER_ADDR] => 10.34.11.56
[SERVER_ADMIN] => webmas...@chilldata.com
[SERVER_NAME] => www.chilldata.com
[SERVER_PORT] => 80
[SERVER_PROTOCOL] => HTTP/1.1
[SERVER_SIGNATURE] =>
[SERVER_SOFTWARE] => Apache
[UNIQUE_ID] => TyOIZK3Hp1AAADUKGtYL
[PHP_SELF] => /dev/soap.php
[REQUEST_TIME] => 1327728740
[argv] => Array
(
[0] => check=1
)
[argc] => 1
)
and if i change to see the $_SERVER['HTTP_USER_AGENT'] variable I get also foo
[2012-01-28 12:31:41] mail at tomsommer dot dk
Regarding your patch, I believe the header is "User-Agent", not "User Agent" :)
[2012-01-28 09:03:56] carloschilazo at gmail dot com
Oooh sorry, my bad; yeah you were right;
I've posted a fix, I already tested it with no problem, waiting for someone to
comment or commit.
[2012-01-27 10:45:04] mail at tomsommer dot dk
I've tested it on several machines.
It's not a matter of stripping the header, since stream_context works.
My test script:
http://example.com/soap.php?check=1',
array('user_agent' => 'foo'));
}
?>
[2012-01-27 05:07:27] carloschilazo at gmail dot com
Forgot to mention, I tested with 5.3.9 realeased version, and also with the
current snapshot
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
https://bugs.php.net/bug.php?id=60887
--
Edit this bug report at https://bugs.php.net/bug.php?id=60887&edit=1
Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header
Edit report at https://bugs.php.net/bug.php?id=60887&edit=1
ID: 60887
Comment by: carloschilazo at gmail dot com
Reported by:mail at tomsommer dot dk
Summary:SoapClient ignores user_agent option and sends no
User-Agent header
Status: Open
Type: Bug
Package:SOAP related
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
This is what I now get after running your script with my patch
Array
(
[DOCUMENT_ROOT] => /home/chilld/public_html
[GATEWAY_INTERFACE] => CGI/1.1
[HTTP_CONNECTION] => close
[HTTP_HOST] => pfdn.local.chilldata.com
[HTTP_USER_AGENT] => foo
[PATH] => /bin:/usr/bin
[QUERY_STRING] => check=1
[REDIRECT_STATUS] => 200
[REMOTE_ADDR] => 189.253.78.75
[REMOTE_PORT] => 20615
[REQUEST_METHOD] => GET
[REQUEST_URI] => /dev/soap.php?check=1
[SCRIPT_FILENAME] => /home/chilld/public_html/dev/soap.php
[SCRIPT_NAME] => /dev/soap.php
[SERVER_ADDR] => 10.34.11.56
[SERVER_ADMIN] => webmas...@chilldata.com
[SERVER_NAME] => www.chilldata.com
[SERVER_PORT] => 80
[SERVER_PROTOCOL] => HTTP/1.1
[SERVER_SIGNATURE] =>
[SERVER_SOFTWARE] => Apache
[UNIQUE_ID] => TyOIZK3Hp1AAADUKGtYL
[PHP_SELF] => /dev/soap.php
[REQUEST_TIME] => 1327728740
[argv] => Array
(
[0] => check=1
)
[argc] => 1
)
and if i change to see the $_SERVER['HTTP_USER_AGENT'] variable I get also foo
Previous Comments:
[2012-01-28 12:31:41] mail at tomsommer dot dk
Regarding your patch, I believe the header is "User-Agent", not "User Agent" :)
------------
[2012-01-28 09:03:56] carloschilazo at gmail dot com
Oooh sorry, my bad; yeah you were right;
I've posted a fix, I already tested it with no problem, waiting for someone to
comment or commit.
[2012-01-27 10:45:04] mail at tomsommer dot dk
I've tested it on several machines.
It's not a matter of stripping the header, since stream_context works.
My test script:
http://example.com/soap.php?check=1',
array('user_agent' => 'foo'));
}
?>
[2012-01-27 05:07:27] carloschilazo at gmail dot com
Forgot to mention, I tested with 5.3.9 realeased version, and also with the
current snapshot
[2012-01-27 05:05:53] carloschilazo at gmail dot com
I could not reproduce your problem, using PHP 5.3.9 (linux) was able to send a
request with user_agent header set
I captured with WireShark could you please try to:
a) capture with another program (maybe)
b) make sure that on the other end , the user_agent is not being stripped
or provide more info
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
https://bugs.php.net/bug.php?id=60887
--
Edit this bug report at https://bugs.php.net/bug.php?id=60887&edit=1
Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header
Edit report at https://bugs.php.net/bug.php?id=60887&edit=1
ID: 60887
Comment by: carloschilazo at gmail dot com
Reported by:mail at tomsommer dot dk
Summary:SoapClient ignores user_agent option and sends no
User-Agent header
Status: Open
Type: Bug
Package:SOAP related
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Oooh sorry, my bad; yeah you were right;
I've posted a fix, I already tested it with no problem, waiting for someone to
comment or commit.
Previous Comments:
[2012-01-27 10:45:04] mail at tomsommer dot dk
I've tested it on several machines.
It's not a matter of stripping the header, since stream_context works.
My test script:
http://example.com/soap.php?check=1',
array('user_agent' => 'foo'));
}
?>
------------
[2012-01-27 05:07:27] carloschilazo at gmail dot com
Forgot to mention, I tested with 5.3.9 realeased version, and also with the
current snapshot
------------
[2012-01-27 05:05:53] carloschilazo at gmail dot com
I could not reproduce your problem, using PHP 5.3.9 (linux) was able to send a
request with user_agent header set
I captured with WireShark could you please try to:
a) capture with another program (maybe)
b) make sure that on the other end , the user_agent is not being stripped
or provide more info
[2012-01-26 07:16:20] mail at tomsommer dot dk
Workaround is:
$opts = array(
'http'=>array(
'user_agent' => 'foo'
)
);
$context = stream_context_create($opts);
$client = new SoapClient('http://www.example.com/', array('stream_context' =>
$context));
[2012-01-25 20:55:06] mail at tomsommer dot dk
The receiving server only receive the following headers:
GET / HTTP/1.1
Host: www.example.com
Connection: close
Checked with tcpdump
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
https://bugs.php.net/bug.php?id=60887
--
Edit this bug report at https://bugs.php.net/bug.php?id=60887&edit=1
Bug #60785 [Com]: Memory leak in IntlDateFormatter constructor
Edit report at https://bugs.php.net/bug.php?id=60785&edit=1 ID: 60785 Comment by: carloschilazo at gmail dot com Reported by:tim at digicol dot de Summary:Memory leak in IntlDateFormatter constructor Status: Open Type: Bug Package:I18N and L10N related Operating System: Linux 2.6.32 x86_64 CentOS 6.2 PHP Version:5.3.9 Block user comment: N Private report: N New Comment: If you unset the variable right after you create it, does the memory usage still increases? ? Previous Comments: [2012-01-17 22:34:18] tim at digicol dot de The phpinfo "intl" section says: Internationalization support => enabled version => 1.1.0 ICU version => 4.2.1 [2012-01-17 22:14:51] tim at digicol dot de Description: Each time I create a new IntlDateFormatter instance, PHP 5.3.9 leaks memory. You can see in "top" that the RES column (resident size) keeps growing as long as the script is running; up to more than 500 MB for my example. (By the way, memory_get_usage() and the PHP memory limit don't report or act on this.) I've noticed this because we're using long-running scripts with the PHP CLI - they eventually die when too much memory is used. This happens to me with older 5.3.x versions as well. I tested with PHP 5.3.9 built with "./configure --enable-intl" on 64bit CentOS 6.2, running in VMware Fusion on my Mac. Thanks for looking into this, and for the great work on PHP! Test script: --- Expected result: [digicol@dcxcentos6vm ~]$ /usr/local/src/php-5.3.9/sapi/cli/php leak.php Run 'top -p 7211' in another shell to watch memory usage grow... [digicol@dcxcentos6vm ~]$ top -p 7211 top - 00:13:05 up 12:37, 3 users, load average: 0.34, 0.26, 0.34 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 10.1%us, 3.7%sy, 0.0%ni, 79.7%id, 6.1%wa, 0.1%hi, 0.3%si, 0.0%st Mem: 2054984k total, 1515064k used, 539920k free, 111760k buffers Swap: 511992k total, 511992k used,0k free, 121912k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7211 digicol 20 0 406m 21m 10m S 0.0 1.1 0:00.06 php Actual result: -- [digicol@dcxcentos6vm ~]$ /usr/local/src/php-5.3.9/sapi/cli/php leak.php Run 'top -p 7211' in another shell to watch memory usage grow... [digicol@dcxcentos6vm ~]$ top -p 7211 top - 00:01:18 up 12:26, 3 users, load average: 0.95, 0.65, 0.50 Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie Cpu(s): 96.0%us, 3.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st Mem: 2054984k total, 1985784k used,69200k free,68784k buffers Swap: 511992k total, 511860k used, 132k free, 122068k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7211 digicol 20 0 908m 524m 10m R 97.9 26.2 1:15.58 php -- Edit this bug report at https://bugs.php.net/bug.php?id=60785&edit=1
Bug #60704 [Com]: unlink() bug with some files path
Edit report at https://bugs.php.net/bug.php?id=60704&edit=1
ID: 60704
Comment by: carloschilazo at gmail dot com
Reported by:dean at dacunha dot net
Summary:unlink() bug with some files path
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Linux 3.0.0-14-generic #23-Ubunt
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Does this happen also in 5.3.9 ?
Please confirm so I can look into it
Thanks
Previous Comments:
[2012-01-10 19:58:07] dean at dacunha dot net
Description:
unlink() function truncates the file path name argument in some cases.
This bug appears also with the rename() function in the same cases.
The given source code use link() to duplicate a file, then unlink() to remove
the
source file. link() function works and unlink() bugs.
Test script:
---
#!/usr/local/bin/php
Expected result:
unlink() should remove the "/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado -
Angel's Robot List.mp3" file
Actual result:
--
root@djavanubu:/# ./b.php
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /b.php on line 8
###
below trace shows the truncated file path given to unlink() syscall:
[...]
lstat("/mnt/M://BRASIL", {st_mode=S_IFDIR|0755, st_size=69632, ...}) = 0
link("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3", "/mnt/M:/NEWBASE/BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's
Robot List.1.2.mp3") = 0
unlink("BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot List.mp3") = -1
ENOENT (No such file or directory)
write(1, "\nWarning: unlink(BRASIL/Carlinho"..., 130
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /b.php on line 8
) = 130
[...]
--
Edit this bug report at https://bugs.php.net/bug.php?id=60704&edit=1
Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header
Edit report at https://bugs.php.net/bug.php?id=60887&edit=1
ID: 60887
Comment by: carloschilazo at gmail dot com
Reported by:mail at tomsommer dot dk
Summary:SoapClient ignores user_agent option and sends no
User-Agent header
Status: Open
Type: Bug
Package:SOAP related
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Forgot to mention, I tested with 5.3.9 realeased version, and also with the
current snapshot
Previous Comments:
[2012-01-27 05:05:53] carloschilazo at gmail dot com
I could not reproduce your problem, using PHP 5.3.9 (linux) was able to send a
request with user_agent header set
I captured with WireShark could you please try to:
a) capture with another program (maybe)
b) make sure that on the other end , the user_agent is not being stripped
or provide more info
[2012-01-26 07:16:20] mail at tomsommer dot dk
Workaround is:
$opts = array(
'http'=>array(
'user_agent' => 'foo'
)
);
$context = stream_context_create($opts);
$client = new SoapClient('http://www.example.com/', array('stream_context' =>
$context));
[2012-01-25 20:55:06] mail at tomsommer dot dk
The receiving server only receive the following headers:
GET / HTTP/1.1
Host: www.example.com
Connection: close
Checked with tcpdump
[2012-01-25 20:45:55] mail at tomsommer dot dk
Description:
The SoapClient ignores the "user_agent" option, and sends no User-Agent at all.
Test script:
---
$client = new SoapClient('http://www.example.com/', array('user_agent' =>
'foo'));
Expected result:
User-Agent header on the remote server
Actual result:
--
No User-Agent header on the remote server
--
Edit this bug report at https://bugs.php.net/bug.php?id=60887&edit=1
Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header
Edit report at https://bugs.php.net/bug.php?id=60887&edit=1
ID: 60887
Comment by: carloschilazo at gmail dot com
Reported by:mail at tomsommer dot dk
Summary:SoapClient ignores user_agent option and sends no
User-Agent header
Status: Open
Type: Bug
Package:SOAP related
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
I could not reproduce your problem, using PHP 5.3.9 (linux) was able to send a
request with user_agent header set
I captured with WireShark could you please try to:
a) capture with another program (maybe)
b) make sure that on the other end , the user_agent is not being stripped
or provide more info
Previous Comments:
[2012-01-26 07:16:20] mail at tomsommer dot dk
Workaround is:
$opts = array(
'http'=>array(
'user_agent' => 'foo'
)
);
$context = stream_context_create($opts);
$client = new SoapClient('http://www.example.com/', array('stream_context' =>
$context));
[2012-01-25 20:55:06] mail at tomsommer dot dk
The receiving server only receive the following headers:
GET / HTTP/1.1
Host: www.example.com
Connection: close
Checked with tcpdump
[2012-01-25 20:45:55] mail at tomsommer dot dk
Description:
The SoapClient ignores the "user_agent" option, and sends no User-Agent at all.
Test script:
---
$client = new SoapClient('http://www.example.com/', array('user_agent' =>
'foo'));
Expected result:
User-Agent header on the remote server
Actual result:
--
No User-Agent header on the remote server
--
Edit this bug report at https://bugs.php.net/bug.php?id=60887&edit=1
Req #60836 [Com]: Improve array_intersect_key performance
Edit report at https://bugs.php.net/bug.php?id=60836&edit=1
ID: 60836
Comment by: carloschilazo at gmail dot com
Reported by:oliver at hofff dot com
Summary:Improve array_intersect_key performance
Status: Open
Type: Feature/Change Request
Package:Arrays related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
we cant start walking the shortest array given, because we first need to know
which elements we need to look in the other arrays, and those are the ones
presesnt in the first array
" returns an array containing all the entries of array1 which have keys that
are
present in all the arguments. "
Previous Comments:
[2012-01-22 00:34:49] oliver at hofff dot com
Description:
The trivial test script below runs longer than the extpected "instant"
execution (lot longer).
This is because the algorithm walks the first argument and looks up the key in
every other array supplied as an argument.
Instead it should walk the shortest array given, and look up the keys in every
other array.
Maybe this issue or similar ones also apply to other array functions, which
perform set operations, but I have not checked the code of them.
Of course the optimization could be done in userland, but that feels not right.
Test script:
---
$arr = array_fill(0, 100, '...');
$i = 1000;
while($i--) {
array_intersect_key($arr, array());
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60836&edit=1
Req #60872 [Com]: server-side comment tag
Edit report at https://bugs.php.net/bug.php?id=60872&edit=1 ID: 60872 Comment by: carloschilazo at gmail dot com Reported by:mantoxpub at people dot it Summary:server-side comment tag Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Why not use /* comment */ or // comment ? Previous Comments: [2012-01-24 19:16:02] mantoxpub at people dot it Description: --- >From manual page: http://www.php.net/language.basic-syntax.comments --- what about supporting server-side comment tag? Test script: --- <%-- this is a server-side comment. --%> Expected result: (nothing :) Actual result: -- <%-- this is a server-side comment. --%> -- Edit this bug report at https://bugs.php.net/bug.php?id=60872&edit=1
Bug #60756 [Com]: Unable to upgrade
Edit report at https://bugs.php.net/bug.php?id=60756&edit=1 ID: 60756 Comment by: carloschilazo at gmail dot com Reported by:lucien_sabre at yahoo dot it Summary:Unable to upgrade Status: Open Type: Bug Package:*General Issues Operating System: Windows7 32Bit PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Try installing as an administrator (right click the installer, run as administrator) or disable windows UAC Previous Comments: [2012-01-18 07:53:41] lucien_sabre at yahoo dot it So, what do I do? [2012-01-17 19:59:46] anon at anon dot anon It's not moronic to be a beginner, it's moronic to not just try it and learn by experimentation. [2012-01-16 15:29:13] lucien_sabre at yahoo dot it Once I back up the original files, what do I do? I'm a complete beginner ***moron*** in these cases [2012-01-16 14:53:38] anon at anon dot anon So back up the install folder first then. But I doubt it can be too strangely laid out because I've never had a problem just running copies of PHP arbitrarily from extracted zips. [2012-01-16 13:07:13] lucien_sabre at yahoo dot it I tried downloading the zipped version, to simply overwrite the existing files, but I didn't understand where to put the files - and I'm a bit afraid of messing up current installation. 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 https://bugs.php.net/bug.php?id=60756 -- Edit this bug report at https://bugs.php.net/bug.php?id=60756&edit=1
Bug #60876 [Com]: max_input_vars corrupt posted data
Edit report at https://bugs.php.net/bug.php?id=60876&edit=1 ID: 60876 Comment by: carloschilazo at gmail dot com Reported by:jiri dot reischig at ecn dot cz Summary:max_input_vars corrupt posted data Status: Open Type: Bug Package:*General Issues PHP Version:5.3.9 Block user comment: N Private report: N New Comment: I'm not sure as it would have to absolutley halt the execution; Some routines maybe in the script to handle those kind of situations, hence only a warning is issued Previous Comments: [2012-01-25 10:03:16] jiri dot reischig at ecn dot cz Description: When you post some data to the php script where are more variables than limit in max_input_vars the php script does not get any information that php don't put any of data to the system variables (for example $_REQUEST[]). There is only "PHP Warning" generated but the php script is still running without any problem with corrupted dataset from post. Solution will be to stop executing the script if max_input_vars is reached. Without stoping the script you are working with currupted dataset and you can make some data inconsistencies in your aplication without any knowledge. Test script: --- max_input_vars = 1 sending post: test.php?a=1&b=2&c=3 print_r($_REQUEST); Expected result: Stop the script if max_input_vars is reached. Actual result: -- Array ( [a] => 1 ) -- Edit this bug report at https://bugs.php.net/bug.php?id=60876&edit=1
