Bug #49139 [Com]: proc_open requires double quotes
Edit report at https://bugs.php.net/bug.php?id=49139edit=1
ID: 49139
Comment by: ku at digitaldolphins dot jp
Reported by:david dot gausmann at measx dot com
Summary:proc_open requires double quotes
Status: No Feedback
Type: Bug
Package:Program Execution
Operating System: win32 only - Windows XP SP3
PHP Version:5.3.0
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I have same problem too, php 5.4.17 on Windows 7 SP1 x64.
I tried bypass_shell and it was ok: array(bypass_shell = TRUE)
http://php.net/manual/en/function.proc-open.php
It seems that CMD.exe has trick. Check:
CMD.exe /?
or
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-
us/cmd.mspx?mfr=true
---
Starts a new instance of the Windows command interpreter
CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF]
[[/S] [/C | /K] string]
...
If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote () characters:
1. If all of the following conditions are met, then quote characters
on the command line are preserved:
- no /S switch
- exactly two quote characters
- no special characters between the two quote characters,
where special is one of: ()@^|
- there are one or more whitespace characters between the
two quote characters
- the string between the two quote characters is the name
of an executable file.
2. Otherwise, old behavior is to see if the first character is
a quote character and if so, strip the leading character and
remove the last quote character on the command line, preserving
any text after the last quote character.
---
Check the bypass_shell code around CreateProcess. ext\standard\proc_open.c
if (bypass_shell) {
newprocok = CreateProcess(NULL, command, security, security, TRUE,
dwCreateFlags, env.envp, cwd, si, pi);
} else {
spprintf(command_with_cmd, 0, %s /c %s, COMSPEC_NT, command);
newprocok = CreateProcess(NULL, command_with_cmd, security, security, TRUE,
dwCreateFlags, env.envp, cwd, si, pi);
efree(command_with_cmd);
}
---
We simulate the form %s /c %s.
The result depends on the place where we have double quotes.
CMD /C C:\Program Files\Internet Explorer\iexplore.exe
http://php.net
- Ok
CMD /C C:\Program Files\Internet Explorer\iexplore.exe
http://php.net;
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
- ERR
CMD /C C:\Program Files\Internet Explorer\iexplore.exe
http://php.net;
- Ok
---
Workarounds for now:
- Enclose entire command with double quotes.
- array(bypass_shell = TRUE)
Previous Comments:
[2013-02-18 00:33:58] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2012-03-13 12:55:54] david dot gausmann at measx dot com
This bug is still present in PHP 5.4.
According to my previous example I've replaced the command line by the php
interpreter and the reference to a script:
$cmd = 'd:\php-5.4.0\php.exe C:\xampp\htdocs\Neuer Ordner\script2.php';
If I execute your script with the command line above I will get the following
output:
-
D:\php-5.4.0php -f C:\xampp\htdocs\testx.php
string(0)
string(0)
string(93) Die Syntax für den Dateinamen, Verzeichnisnamen oder die
Datenträger
bezeichnung ist falsch.
exec:
Lorem ipsum
Array
(
[0] = Lorem ipsum
)
-
If I move the file script2.php to an other location (without any spaces in
it's path) then it works if I remove the double quotes from the parameter.
So the error only occurs if the parameters use double quotes, too.
In your example no parameters were used, so the error doesn't occured.
I've tested this with PHP 5.4 on Windows XP SP3.
[2011-02-09 12:22:15] paj...@php.net
@xandrani at googlemail dot com
'c:\program files\doxygen\bin\doxygen.exe C:\fred\doxyfile'
works fine with proc_open.
For the initial comment and other:
?php
echo PHP_EOL;
error_reporting(E_ALL|E_NOTICE);
$cmd = 'c:\\Program Files (x86)\\wcat\\wcutil.exe';
$des = array
(
0 = array('pipe', 'r'),
1 = array('pipe', 'w'),
2 = array('pipe', 'w')
);
$resource = proc_open($cmd, $des, $pipes, null, $_ENV);
Bug #65247 [Opn-Fbk]: php.exe crashes when opcache.enable_cli=1
Edit report at https://bugs.php.net/bug.php?id=65247edit=1 ID: 65247 Updated by: a...@php.net Reported by:me at laurinkeithdavis dot com Summary:php.exe crashes when opcache.enable_cli=1 -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows 7 x64 PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Firstly, please try to disable xdebug. And, which opcache build do you use? Does it crash when fastcgi doesn't run simultaneously on the same machine? Please look at the link above about howto produce a backtrace. Previous Comments: [2013-07-11 23:40:11] me at laurinkeithdavis dot com Description: If Opcache is enabled for CLI, php.exe crashes on shutdown every single time, on 3 different machines. No crashes on fastcgi (IIS 7.5), and no crashes on CLI if opcache is disabled. Always happens on shutdown, tested with XDebug, after script completes (as far as I can tell.) Test script: --- Any script will do. Expected result: No errors Actual result: -- Log Name: Application Source:Application Error Date: 7/10/2013 3:39:44 PM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: KDAVIS.pridedallas.com Description: Faulting application name: php.exe, version: 5.5.0.0, time stamp: 0x51c23964 Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b8f Exception code: 0xc374 Fault offset: 0x000ce6c3 Faulting process id: 0x7f1c Faulting application start time: 0x01ce7dad93743640 Faulting application path: C:\PHP\php.exe Faulting module path: C:\Windows\SysWOW64\ntdll.dll Report Id: da2aff4c-e9a0-11e2-b56d-bc5ff42044ec -- Edit this bug report at https://bugs.php.net/bug.php?id=65247edit=1
Bug #64868 [Com]: segfault in zval_mark_grey(), Zend/zend_gc.c:421
Edit report at https://bugs.php.net/bug.php?id=64868edit=1 ID: 64868 Comment by: ulrich dot schmidt-goertz at gmx dot de Reported by:martin dot schuette at icans-gmbh dot com Summary:segfault in zval_mark_grey(), Zend/zend_gc.c:421 Status: Feedback Type: Bug Package:Reproducible crash Operating System: Debian Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: I've experienced the same issue on Ubuntu. $ php -v PHP 5.4.6-1ubuntu1.2 (cli) (built: Mar 11 2013 14:57:54) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans Previous Comments: [2013-06-22 09:18:15] larue...@php.net Hey, after a second look into your backtrace, seems you are running with php5.4.4? then this segfault is very like and should be fixed in #63055 https://github.com/php/php-src/commit/e88cdaa0 please try with the newer php version. [2013-05-29 19:14:33] Sjon at hortensius dot net Well pinpointing this should be easy; open PHPUnit_Util_Test and look for the usage of REGEX_REQUIRES (which is in your trace). Var dump the parameters and tell us which ones were passed that caused that caused the segfault? [2013-05-21 10:09:13] martin dot schuette at icans-gmbh dot com So far I was unable to reproduce the crash with a smaller code sample (i.e. without requiring our complete application and test suite). [2013-05-17 10:57:43] larue...@php.net could you please provide a reproduce test script? thanks [2013-05-17 10:47:30] martin dot schuette at icans-gmbh dot com Description: As part of a PHPUnit test suite I get this segfault. Interestingly it depends on phpunit's command line options. Segfault with phpunit -c app/phpunit.xml.dist --log-junit /dev/null No problem with phpunit -c app/phpunit.xml.dist and phpunit -c app/phpunit.xml.dist --log-junit /dev/null --debug Without GC it works as well: php -dzend.enable_gc=0 /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null Expected result: complete PHPUnit run Actual result: -- deploy@jenkins:/tmp/gitphp -v PHP 5.4.4-14 (cli) (built: Mar 4 2013 14:08:43) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies deploy@jenkins:/tmp/gitgdb --args php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/php...Reading symbols from /usr/lib/debug/usr/bin/php5...done. done. (gdb) run Starting program: /usr/bin/php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). [New Thread 0x7fffe80d8700 (LWP 27679)] [Thread 0x7fffe80d8700 (LWP 27679) exited] PHPUnit 3.7.10 by Sebastian Bergmann. Configuration read from /tmp/git/app/phpunit.xml.dist . 61 / 3421 ( 1%) ...S. 122 / 3421 ( 3%)
Bug #61354 [Com]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354edit=1 ID: 61354 Comment by: tototation at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Yes, i'm interested too to understand that fact. I recently upgrade my server, and ALL my code is unusable ! A search in code found +470 000 words htmlentities or htmlspecialchars ! HOW TO CHANGE ALL THIS ? THAT'S IMPOSSIBLE Thanks, we must stop all our services and websites. Just for a stupid thing. Previous Comments: [2013-06-15 22:51:31] jbolder42 at yahoo dot com I was wondering if someone could enlighten me by explaining why this: htmlspecialchars($str, ENT_QUOTES, ISO-8859-1); ... would be considered any more secure than something like this: ini_set(html.default_charset, ISO-8859-1); htmlspecialchars($str, ENT_QUOTES); Thank you! [2013-05-20 18:14:25] kstirn at gmail dot com @minder at ufive dot unibe dot ch Yes, this can be done, but still means we would have to manually modify hundreds of legacy scripts on the server (many third party and many obfuscated/encoded) to be able to upgrade to PHP 5.4. It would be really easy to fix with an ini setting and it would indeed make sense to have a setting for such a huge default change. I am disappointed that the PHP dev team has decided to completely ignore the issue. [2013-05-19 13:10:13] minder at ufive dot unibe dot ch For legacy projects in latin1 we substitute htmlspecialchars with the self-made function htmlXspecialchars according to these instructions: http://ufive.unibe.ch/?c=php54entitiesfixq=l=e [2013-02-26 21:29:02] rudibr at gmail dot com What about my third-party modules? Should I change their code as well? Do I now need to verify and manually alter code on third-party modules everytime I upgrade or install them? If Im using a component with protected code, do I need to go trough their support staff and wait for a correction? What if they provide no reliable support or customization, am I now being encouraged to hack and crack in the source code just so I can fix this? It is easy , even redundant , and absolutely justfiable to create a new ini setting to control this behavior, that I feel a little bit offended by the current attitude of php developers over this issue. I also feel a little bit offended because the guy who is responsible for this change EXPLICITLY stated that the change to UTF-8 defaulting have nothing to do with security. It just sounded like a better default, according to the developer. Hardly a seriously thought-trough consideration. This is becoming quite a sad state of affairs. I guess I will have to consider moving on from php if it comes to that. [2013-01-27 17:32:18] kstirn at gmail dot com It will soon be a year since the release of PHP 5.4 and there still is no easy way (read: a global PHP setting) to overcome this huge backwards-incompatibility. PHP developers, I understand the security concerns, but please don't be so stubborn and give us an option to set a default setting without having to modify *all* legacy code to work with 5.4. Your action (or lack thereof) is producing the opposite results of desired - instead of moving to PHP 5.4, thousands of servers (including several we own) will stay with 5.3.x even after end of life cycle in March 2013. *Fact* A simple global setting (an optional php.ini value) would solve the issue for thousands of users while addressing security issues by explicitly defining the default charset to be used by affected functions - all without having to rewrite existing code. PHP team please do reconsider this and help everyone not using UTF-8 move to PHP 5.4. Thank you! 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=61354 -- Edit this bug report at https://bugs.php.net/bug.php?id=61354edit=1
Req #65244 [Opn]: function_exist() returns false when using imported namespace alias
Edit report at https://bugs.php.net/bug.php?id=65244edit=1
ID: 65244
Updated by: a...@php.net
Reported by:strategycon at yahoo dot com
Summary:function_exist() returns false when using imported
namespace alias
Status: Open
Type: Feature/Change Request
Package:Reflection related
Operating System: Ubuntu
PHP Version:5.3Git-2013-07-11 (snap)
Block user comment: N
Private report: N
New Comment:
Compile vs. execution phase is that.
Previous Comments:
[2013-07-11 15:47:36] strategycon at yahoo dot com
Description:
namespace mynamespace;
use Symfony\Component\Validator\Constraints as Assert;
class myClass
{
function classExists($name == 'NotBlank')
{
return function_exists('Assert\\' . $name)
}
function classExistsExt($name == 'NotBlank')
{
return function_exists('Symfony\Component\Validator\Constraints\\' .
$name)
}
}
myClass::classExists()
// returns false
myClass::classExists()
// returns true
Expected result:
To fully benefit from namespace importing and aliasing, I would expect that
method to return true when namespace alias is used instead of full/original one.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65244edit=1
Req #17617 [Opn-Wfx]: levenshtein() param for faster return
Edit report at https://bugs.php.net/bug.php?id=17617edit=1 ID: 17617 Updated by: maar...@php.net Reported by:gonfidentschal at hotmail dot com Summary:levenshtein() param for faster return -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: all PHP Version:4.1.2 Block user comment: N Private report: N New Comment: No response in 11 years, so safe to conclude that there's little interest in this feature. Also a very good change issue starter also has moved on (other project / chosen better algorithm). Previous Comments: [2002-06-05 18:33:57] gonfidentschal at hotmail dot com in my case, i want to find strings that are similar to a given one. so a lev() return of 2 means i throw that string away. maybe another param to levenshtein() could help speed up the function, in that it could return when the 3rd mismatch was found. it would not have to do it's job to the end. anyway, i'm surprised how fast it is already. :) greetings fab -- Edit this bug report at https://bugs.php.net/bug.php?id=17617edit=1
Req #15232 [Opn-NoF]: Need a possibility to compare two references
Edit report at https://bugs.php.net/bug.php?id=15232edit=1 ID: 15232 Updated by: maar...@php.net Reported by:flying at dom dot natm dot ru Summary:Need a possibility to compare two references -Status: Open +Status: No Feedback Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: All PHP Version:4.0.6 Block user comment: N Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Re-Opened. Thank you. Previous Comments: [2011-08-23 14:19:43] datib...@php.net For scalar values, this is impossible. And you probably don't want this either, because $a and $b might actually point to the same value (e.g. due to compiler optimization) For objects you could use the equality operator (===). For example: $a = new mynumber(5); $b = new mynumber(5); echo $a === $b; [2002-01-26 06:18:25] flying at dom dot natm dot ru PHP have no possiblity to find, if two references points to the same actual variable, but sometimes it is necesary. Short example: $a = 5; $b = 5; $a_ref1 = $a; $a_ref2 = $a; $b_ref = $b; PHP needs a function (or operator) which will return TRUE, when comparing $a_ref1 and $a_ref2, but FALSE, if comparing $a_ref1 and $b_ref. -- Edit this bug report at https://bugs.php.net/bug.php?id=15232edit=1
Req #17565 [Opn-Wfx]: optional ORDER parameter for range()
Edit report at https://bugs.php.net/bug.php?id=17565edit=1 ID: 17565 Updated by: maar...@php.net Reported by:bigredlinux at yahoo dot com Summary:optional ORDER parameter for range() -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Linux PHP Version:4.2.1 Block user comment: N Private report: N New Comment: Just add an if condition for your business rules where you expect an empty array. Previous Comments: [2011-08-23 14:42:44] datib...@php.net range() now has that option since 5.0, though it will still assume the step size is negative when the start value is higher than the end value. [2002-06-02 05:52:40] bigredlinux at yahoo dot com The range() function has the ability to generate a range from one number (or character) to another. It states in the documentation that if the first number (character) is greater than the second, it creates a decreasing range. However, the problem is, sometimes you don't want it to switch range order, so it would be nice to have a third parameter which states the direction or states whether you want it to auto flip. Hence, if I did range(9, 0, ASC) it would generate an empty array... or prehaps I could do range(9, 0, false) for not autoflipping. -- Edit this bug report at https://bugs.php.net/bug.php?id=17565edit=1
Req #14896 [Opn-Wfx]: Multi threaded support
Edit report at https://bugs.php.net/bug.php?id=14896edit=1 ID: 14896 Updated by: maar...@php.net Reported by:alan_k at akbkhome dot com Summary:Multi threaded support -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: All PHP Version:4.0CVS-2002-01-06 Block user comment: N Private report: N New Comment: Language won't support this feature. Previous Comments: [2002-01-06 20:23:10] alan_k at akbkhome dot com Couldnt find it in the database so I thought I better add it. $id = thread_create(function_or_object_method); thread_stop($id); * especially so that global vars etc. are available in the other threads.. - without resorting to shm + pcntl similar to perl?/pike/python etc. This would be useful for PHP-GTK apps. (albeit not essential) - although Its one of those be-carefull features :) -- Edit this bug report at https://bugs.php.net/bug.php?id=14896edit=1
Req #19245 [Opn-Wfx]: Alter error message for execution time exceeded
Edit report at https://bugs.php.net/bug.php?id=19245edit=1 ID: 19245 Updated by: maar...@php.net Reported by:t_o_m_ at yahoo dot com Summary:Alter error message for execution time exceeded -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: All PHP Version:4.2.2 Block user comment: N Private report: N New Comment: You can view your access logs to see which request caused the timeout. And if you conclude you're waiting on sql, you can watch the slow query log (or even always keep an eye on slow queries) As there are other logs available, no need to add 1 arbitrary (debugging might depend on others) variable to this message... Previous Comments: [2002-09-05 06:49:08] t_o_m_ at yahoo dot com I have the log_errors and error_log set in my php.ini. However when I look through it I see lines like: [05-Sep-2002 10:03:31] PHP Fatal error: Maximum execution time of 30 seconds exceeded in E:\intranet\reports\db.inc on line 9 This file is includeded in many other files, and from this error it is not possible to tell which the including file was. In my case the including file contains an over complex sql statement, the include file (db.inc) just runs it. Would it be possible for this error message to have $_SERVER['PHP_SELF'] in it? -- Edit this bug report at https://bugs.php.net/bug.php?id=19245edit=1
Req #18675 [Opn-Wfx]: aborting scripts when user hits stop in browser
Edit report at https://bugs.php.net/bug.php?id=18675edit=1 ID: 18675 Updated by: maar...@php.net Reported by:radu dot rendec at ines dot ro Summary:aborting scripts when user hits stop in browser -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: any PHP Version:4.2.2 Block user comment: N Private report: N New Comment: This is no safeguard against buggy code. For instance, for your example: all I have to do to keep your server bussy is to keep open a few connections... B) Previous Comments: [2002-07-31 12:23:15] radu dot rendec at ines dot ro The default behavior, as reported in the documentation, is to abort scripts with the ABORTED flag on _when the script tries to output something_. This may lead to a security issue. Suppose that a malicious (or dummy) user of a shared web hosting system makes a dead loop in a script and no output is produced inside that loop. Moreover, the script makes some system calls inside that loop so the time limit counter is slowly incremented (or even not incremented at all). So the time limit protection won't work, and neither the ABORTED flag protection (because no output is made inside the loop). If a remote user tries to access the broken script via the browser and hits the stop button, the script will run on the server for ever, causing serious load. If more users try to access the broken script (or the same user tries to access it more times), the server will have a huge load and will soon be unusable. I suggest the default behavior be to abort the execution of the script as soon as the connection is aborted. -- Edit this bug report at https://bugs.php.net/bug.php?id=18675edit=1
Req #19607 [Opn-Wfx]: Fourth argument for htmlentities()
Edit report at https://bugs.php.net/bug.php?id=19607edit=1 ID: 19607 Updated by: maar...@php.net Reported by:marcel_normann at gmx dot net Summary:Fourth argument for htmlentities() -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: all PHP Version:4CVS-2002-09-26 Block user comment: N Private report: N New Comment: No response in 11 years, so safe to conclude that there's little interest in this feature. Also a very good change issue starter also has moved on (other project / workaround like str_replace whitelisted chars afterwards). Previous Comments: [2002-09-26 01:56:36] marcel_normann at gmx dot net Htmlentities() schould have a fourth argument where you can add chars that will not be translated. For example ? echo htmlentites(Umläütß); ? will return Umlauml;uuml;tszlig;, but ? echo htmlentites(Umläütß, .., .., äü); ? will respond Umläütszlig. -- Edit this bug report at https://bugs.php.net/bug.php?id=19607edit=1
Req #65244 [Opn-Wfx]: function_exist() returns false when using imported namespace alias
Edit report at https://bugs.php.net/bug.php?id=65244edit=1
ID: 65244
Updated by: ni...@php.net
Reported by:strategycon at yahoo dot com
Summary:function_exist() returns false when using imported
namespace alias
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Reflection related
Operating System: Ubuntu
PHP Version:5.3Git-2013-07-11 (snap)
Block user comment: N
Private report: N
New Comment:
Function names, class names and generally all names passed as strings are
always fully qualified. For classes PHP 5.5 added the ::class syntax to easily
get the FQCN from an alias.
Previous Comments:
[2013-07-12 12:30:03] a...@php.net
Compile vs. execution phase is that.
[2013-07-11 15:47:36] strategycon at yahoo dot com
Description:
namespace mynamespace;
use Symfony\Component\Validator\Constraints as Assert;
class myClass
{
function classExists($name == 'NotBlank')
{
return function_exists('Assert\\' . $name)
}
function classExistsExt($name == 'NotBlank')
{
return function_exists('Symfony\Component\Validator\Constraints\\' .
$name)
}
}
myClass::classExists()
// returns false
myClass::classExists()
// returns true
Expected result:
To fully benefit from namespace importing and aliasing, I would expect that
method to return true when namespace alias is used instead of full/original one.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65244edit=1
Req #20799 [Opn-Wfx]: Able to call function when reaching a certain line in a certain file
Edit report at https://bugs.php.net/bug.php?id=20799edit=1 ID: 20799 Updated by: maar...@php.net Reported by:powerblade at mail dot dk Summary:Able to call function when reaching a certain line in a certain file -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Windows XP PHP Version:4.2.3 Block user comment: N Private report: N New Comment: No response in 11 years, bad idea (application framework should offer proper hooks), and also outdated since PHP 5 offers full OO features. Previous Comments: [2002-12-03 15:43:38] powerblade at mail dot dk The reason i need this feature is when people wants to make hacks for scripts. Then they often modify the scripts a bit, and add lines everywhere in the script. If you then distribute the hack, you need to tell them where in the script they add the lines. The problem is they already have other hacks installed, so it doesn't look the same. So i thought of a trigger_line() function. load the function with a parameter of filename, line number and function to run, then when it reaches that file/line it runs the function, to do what it needs to do. Then it's easy to have a bunch of hacks to a script, without modifying the code. This would be very very usefull. -- Edit this bug report at https://bugs.php.net/bug.php?id=20799edit=1
Req #21379 [Opn-Wfx]: Add integer to pop and unshift
Edit report at https://bugs.php.net/bug.php?id=21379edit=1 ID: 21379 Updated by: maar...@php.net Reported by:c dot greenNOSP at Mits dot uq dot edu dot au Summary:Add integer to pop and unshift -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: RH 7.3 PHP Version:4.3.0 Block user comment: N Private report: N New Comment: array_slice() does what you want. :) Previous Comments: [2003-01-02 22:10:03] c dot greenNOSP at Mits dot uq dot edu dot au It would be nice if pop and unshift had an optional integer argument. This would be useful for retreiving or removing the first or last n elements of an array. If the default is left as 1, then no current code will be affected, and the functions would be extended in an intuitive way. Cheerio, Cameron Green -- Edit this bug report at https://bugs.php.net/bug.php?id=21379edit=1
Req #21594 [Opn-Wfx]: import construct
Edit report at https://bugs.php.net/bug.php?id=21594edit=1 ID: 21594 Updated by: maar...@php.net Reported by:tazio at nur dot it Summary:import construct -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: all PHP Version:4.3.0 Block user comment: N Private report: N New Comment: It's 10 years later now, and now we've got namespaces and more OO features. Previous Comments: [2003-01-12 06:05:27] tazio at nur dot it could be interesting for OOP a java like import construct importing a selected file with syntax import path/to/my_file.php; which is the same of include / require but also import path/to/my_lib/*; that should import all php files in the directory. -- Edit this bug report at https://bugs.php.net/bug.php?id=21594edit=1
Bug #61354 [Com]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354edit=1 ID: 61354 Comment by: kstirn at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Instead of moving on to PHP 5.4 and PHP 5.5 thousands of servers will stay with legacy PHP 5.3 due to this single, easy to solve (ini setting) issue that the PHP team has decided to ignore. Previous Comments: [2013-07-12 10:57:40] tototation at gmail dot com Yes, i'm interested too to understand that fact. I recently upgrade my server, and ALL my code is unusable ! A search in code found +470 000 words htmlentities or htmlspecialchars ! HOW TO CHANGE ALL THIS ? THAT'S IMPOSSIBLE Thanks, we must stop all our services and websites. Just for a stupid thing. [2013-06-15 22:51:31] jbolder42 at yahoo dot com I was wondering if someone could enlighten me by explaining why this: htmlspecialchars($str, ENT_QUOTES, ISO-8859-1); ... would be considered any more secure than something like this: ini_set(html.default_charset, ISO-8859-1); htmlspecialchars($str, ENT_QUOTES); Thank you! [2013-05-20 18:14:25] kstirn at gmail dot com @minder at ufive dot unibe dot ch Yes, this can be done, but still means we would have to manually modify hundreds of legacy scripts on the server (many third party and many obfuscated/encoded) to be able to upgrade to PHP 5.4. It would be really easy to fix with an ini setting and it would indeed make sense to have a setting for such a huge default change. I am disappointed that the PHP dev team has decided to completely ignore the issue. [2013-05-19 13:10:13] minder at ufive dot unibe dot ch For legacy projects in latin1 we substitute htmlspecialchars with the self-made function htmlXspecialchars according to these instructions: http://ufive.unibe.ch/?c=php54entitiesfixq=l=e [2013-02-26 21:29:02] rudibr at gmail dot com What about my third-party modules? Should I change their code as well? Do I now need to verify and manually alter code on third-party modules everytime I upgrade or install them? If Im using a component with protected code, do I need to go trough their support staff and wait for a correction? What if they provide no reliable support or customization, am I now being encouraged to hack and crack in the source code just so I can fix this? It is easy , even redundant , and absolutely justfiable to create a new ini setting to control this behavior, that I feel a little bit offended by the current attitude of php developers over this issue. I also feel a little bit offended because the guy who is responsible for this change EXPLICITLY stated that the change to UTF-8 defaulting have nothing to do with security. It just sounded like a better default, according to the developer. Hardly a seriously thought-trough consideration. This is becoming quite a sad state of affairs. I guess I will have to consider moving on from php if it comes to that. 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=61354 -- Edit this bug report at https://bugs.php.net/bug.php?id=61354edit=1
[PHP-BUG] Req #65250 [NEW]: PHP form input parsing
From: matti dot jarvinen at nitroid dot fi Operating system: * PHP version: 5.4.17 Package: URL related Bug Type: Feature/Change Request Bug description:PHP form input parsing Description: On some occations PHP has to work with data sent from different sources. Form data parsing with complex data (arrays) differs from the PHP in Ruby, ASP, JSP and the like. It would be highly beneficial for PHP to have _always_ possibility to determine custom input parser. Currently php://input can be only used for this end if input type isn't multipart/form-data. -- Edit bug report at https://bugs.php.net/bug.php?id=65250edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65250r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65250r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65250r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65250r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65250r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65250r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65250r=needscript Try newer version: https://bugs.php.net/fix.php?id=65250r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65250r=support Expected behavior: https://bugs.php.net/fix.php?id=65250r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65250r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65250r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65250r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65250r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65250r=dst IIS Stability: https://bugs.php.net/fix.php?id=65250r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65250r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65250r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65250r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65250r=mysqlcfg
Req #17279 [Opn-Wfx]: array_recurse_safe()
Edit report at https://bugs.php.net/bug.php?id=17279edit=1
ID: 17279
Updated by: maar...@php.net
Reported by:tomat at lenderlabdot dot com
Summary:array_recurse_safe()
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: All
PHP Version:4.1.2
Block user comment: N
Private report: N
New Comment:
Related issue already fixed this problem.
Previous Comments:
[2002-05-16 18:09:50] tomat at lenderlabdot dot com
Will solve problems like:
http://bugs.php.net/bug.php?id=16064
This code doesn't work, but I don't know enough C to write it right. It would
work if PHP had a method for determining if two variables are the same
reference. (unless there is one that I haven't found...)
?php
$a=array(1,2,3);
$a[3]=$a;
$a=array_recurse_safe($a);
array_merge_recursive($a,$a);
var_dump($a);
function array_recurse_safe($array, $parents=array()) {
$parents[]=$array;
foreach($array as $element) {
if(is_array($element) || is_object($element)) {
$loop=false;
foreach($parents as $parent) {
if($parent == $element) {
unset($element);
$loop=true;
}
}
if(!$loop) {
$element=array_recurse_safe($element, $parents);
}
}
}
return $array;
}
?
Also, the usage of unset() is improper here, but I left it in for simplicity.
--
Edit this bug report at https://bugs.php.net/bug.php?id=17279edit=1
[PHP-BUG] Bug #65251 [NEW]: array_merge_recursive() recursion detection broken
From: maarten Operating system: PHP version: 5.5.0 Package: Arrays related Bug Type: Bug Bug description:array_merge_recursive() recursion detection broken Description: ?php array_merge_recursive$GLOBALS,$GLOBALS) ? No longer detects recursion. It was fixed at the time (https://bugs.php.net/bug.php?id=16064 ) and fix did work until PHP 5.3.26 However PHP 5.4.0 shows a regression, still present in recent 5.4 and 5.5. See: http://3v4l.org/PfuC8 Test script: --- ?php array_merge_recursive($GLOBALS,$GLOBALS) Expected result: Warning: array_merge_recursive(): recursion detected in [...] on line 2 Actual result: -- Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 72 bytes) in [...] on line 2 -- Edit bug report at https://bugs.php.net/bug.php?id=65251edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65251r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65251r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65251r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65251r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65251r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65251r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65251r=needscript Try newer version: https://bugs.php.net/fix.php?id=65251r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65251r=support Expected behavior: https://bugs.php.net/fix.php?id=65251r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65251r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65251r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65251r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65251r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65251r=dst IIS Stability: https://bugs.php.net/fix.php?id=65251r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65251r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65251r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65251r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65251r=mysqlcfg
[PHP-BUG] Req #65252 [NEW]: Input string parsing
From: matti dot jarvinen at nitroid dot fi
Operating system: *
PHP version: 5.4.17
Package: URL related
Bug Type: Feature/Change Request
Bug description:Input string parsing
Description:
Since register_globals has been removed in PHP 5.4.0 there should be no
reason other than legacy why input variables ($_POST, $_GET, $_FILES,
$_COOKIE, $_REQUEST) can not have keys containing following characters
chr(32) ( ) (space)
chr(46) (.) (dot)
Documentation states that only . is changed to _ but same goes for above
characters.
http://www.php.net/manual/en/language.variables.external.php
Test script:
---
form method=POST
input type=text name=foo bar value=spaced /
input type=text name=foo.bar value=dotted /
input type=submit value=send /
/form
?php
if(isset($_POST))
{
print_r($_POST);
}
?
Expected:
array(
foo bar='spaced',
foo.bar='dotted'
);
Actual result:
array(
foo_bar='dotted'
);
--
Edit bug report at https://bugs.php.net/bug.php?id=65252edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65252r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65252r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65252r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65252r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65252r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65252r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65252r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65252r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65252r=support
Expected behavior: https://bugs.php.net/fix.php?id=65252r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65252r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65252r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65252r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65252r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65252r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65252r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65252r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65252r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65252r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65252r=mysqlcfg
Bug #64868 [Fbk]: segfault in zval_mark_grey(), Zend/zend_gc.c:421
Edit report at https://bugs.php.net/bug.php?id=64868edit=1 ID: 64868 Updated by: larue...@php.net Reported by:martin dot schuette at icans-gmbh dot com Summary:segfault in zval_mark_grey(), Zend/zend_gc.c:421 Status: Feedback Type: Bug Package:Reproducible crash Operating System: Debian Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ please try with the newer version Previous Comments: [2013-07-12 10:01:59] ulrich dot schmidt-goertz at gmx dot de I've experienced the same issue on Ubuntu. $ php -v PHP 5.4.6-1ubuntu1.2 (cli) (built: Mar 11 2013 14:57:54) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans [2013-06-22 09:18:15] larue...@php.net Hey, after a second look into your backtrace, seems you are running with php5.4.4? then this segfault is very like and should be fixed in #63055 https://github.com/php/php-src/commit/e88cdaa0 please try with the newer php version. [2013-05-29 19:14:33] Sjon at hortensius dot net Well pinpointing this should be easy; open PHPUnit_Util_Test and look for the usage of REGEX_REQUIRES (which is in your trace). Var dump the parameters and tell us which ones were passed that caused that caused the segfault? [2013-05-21 10:09:13] martin dot schuette at icans-gmbh dot com So far I was unable to reproduce the crash with a smaller code sample (i.e. without requiring our complete application and test suite). [2013-05-17 10:57:43] larue...@php.net could you please provide a reproduce test script? thanks 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=64868 -- Edit this bug report at https://bugs.php.net/bug.php?id=64868edit=1
Bug #51516 [Com]: Apache 2.2 won't start after I install PHP (Using .MSI)
Edit report at https://bugs.php.net/bug.php?id=51516edit=1 ID: 51516 Comment by: John at mcmillantech dot co dot uk Reported by:sfoulk526 at gmail dot com Summary:Apache 2.2 won't start after I install PHP (Using .MSI) Status: No Feedback Type: Bug Package:Apache2 related Operating System: Windows 7 PHP Version:5.2.13 Block user comment: N Private report: N New Comment: I've been plagued with the same problem. It turned out that I had installed incompatible versions of Apache and PHP. Previous Comments: [2013-02-18 00:34:12] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2012-10-29 06:38:07] xagic at yahoo dot com Just installed PHP 5.2.17 on Apache 2.2.x and got the same problem. Added full paths at the end of the Apache config file, and it works. Cheers for the help. [2012-10-10 10:08:03] vinod dot wagh at infrasofttech dot com Sorry , please ignore my previous commnets , I am wrong . [2012-10-10 10:05:54] vinod dot wagh at infrasofttech dot com Yeaaahhh ! Got it ! thats booldy MSI installer , messing with slashes . entry in httpd.conf should look like : #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL #PHPIniDir C:/Program Files/PHP/ #LoadModule php5_module C:/Program Files/PHP/php5apache2_2.dll #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL [2012-07-23 10:40:35] panama dot amanap at yahoo dot com dot au Confirm using threadsafe VC6 (php-5.2.17-Win32-VC6-x86.msi) The problem is as carl_armbruster described. Fix your httpd.conf by fully qualifying the file paths. Thanks for the hint. 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=51516 -- Edit this bug report at https://bugs.php.net/bug.php?id=51516edit=1
Bug #62010 [Com]: json_decode produces invalid byte-sequences
Edit report at https://bugs.php.net/bug.php?id=62010edit=1
ID: 62010
Comment by: masakielastic at gmail dot com
Reported by:tklingenberg at lastflood dot net
Summary:json_decode produces invalid byte-sequences
Status: Open
Type: Bug
Package:JSON related
Operating System: Windows
PHP Version:5.3.13
Block user comment: N
Private report: N
New Comment:
Here is RFC 3629's description about UTF-8 definition.
The definition of UTF-8 prohibits encoding character numbers
between U+D800 and U+DFFF, which are reserved for use with the
UTF-16 encoding form (as surrogate pairs) and do not directly
represent characters.
http://tools.ietf.org/html/rfc3629
The following patch solve the part of problem,
The isolated low surrogate pairs(U+DC00 U+DFFF) are replaced with U+FFFD,
The imrovement for high surrogate pairs (U+D800 - U+DBFF) is needed.
https://gist.github.com/masakielastic/5985383
var_dump(
\xef\xbf\xbd === json_decode('\udc00'),
\xef\xbf\xbd.\xed\xa0\x80 === json_decode('\ud800\ud800'),
\xed\xa0\x80 === json_decode('\ud800')
);
The consistency for the following options
(under the discussion) is needed too.
json_encode's option for replacing ill-formd byte sequences
with substitute characters
https://bugs.php.net/bug.php?id=65082
Previous Comments:
[2013-01-11 09:44:55] votefordevnull at gmail dot com
Successfully reproduced on Linux
[2012-05-11 22:46:34] tklingenberg at lastflood dot net
Looks like that #41067 https://bugs.php.net/bug.php?id=41067 was not fully
fixed.
[2012-05-11 22:12:42] tklingenberg at lastflood dot net
Description:
It's a typical case the JSON *and* UTF-16 specifications warn about: decoding
of
non-existing UTF-16 code-points:
json_decode('\ud834')
shoud give NULL because \ud834 is *invalid*. But instead it starts some party,
get's boozed and offers this as UTF-8 byte-sequence:
1110 1101 1010 1011 0100
1110 10xx 10xx
1101 1000 0011 0100
D8 34
U+D834 is not a valid unicode character.
Test script:
---
if (NULL !== json_decode('\ud834')) {
echo json_decode is still broken.;
}
Expected result:
NULL because the json is invalid.
Actual result:
--
PHP tries to create UTF-8 out of it and fails by creating invalid UTF-8 unicode
byte-sequences.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62010edit=1
Req #65082 [Asn]: json_encode's option for replacing ill-formd byte sequences with substitute cha
Edit report at https://bugs.php.net/bug.php?id=65082edit=1 ID: 65082 User updated by:masakielastic at gmail dot com Reported by:masakielastic at gmail dot com Summary:json_encode's option for replacing ill-formd byte sequences with substitute cha Status: Assigned Type: Feature/Change Request Package:JSON related Operating System: All PHP Version:5.5.0 Assigned To:remi Block user comment: N Private report: N New Comment: I posted a patch for handling surrogate pairs since the range (U+D800 - U+DFFF) is not allowed in UTF-8 (RFC 3629). Someone's help is needed for handling high surrogate pairs and the options. https://gist.github.com/masakielastic/5985383 json_decode produces invalid byte-sequences https://bugs.php.net/bug.php?id=62010 Previous Comments: [2013-07-11 09:48:54] masakielastic at gmail dot com Hi, I fixed my patch and added test case for json_decode. [2013-07-11 08:37:51] masakielastic at gmail dot com Hi remi, could you test my patch for PHP_JSON_UNESCAPED_UNICODE option? The patch adopts JSON_NOTUTF8_SUBSTITUTE and JSON_NOTUTF8_IGNORE options. https://gist.github.com/masakielastic/5973095 [2013-07-11 04:59:02] r...@php.net I don't think changing the current behavior is a good idea, the reason why I really prefer some new options. [2013-07-11 04:27:19] masakielastic at gmail dot com Hi, thanks nikic and remi. After several considering, I changed my mind. I think the behavior of substituting U+FFFD for ill-formed sequences should be default. How do you think? We might need the discussion about the consitency for Escaper API. htmlspecialchars's ENT_SUBSTITUTE option is adopted by Symfony and Zend Framework. https://wiki.php.net/rfc/escaper Although the behavior breaks 2 test suites, it don't break user's codebases. A lot of people don't use any option looking in github. https://github.com/search?l=PHPq=json_encoderef=advsearchtype=Code https://github.com/search?l=PHPq=json_decoderef=advsearchtype=Code The same problem can be seen in htmlspecialchars. https://github.com/search?l=PHPq=htmlspecialcharsref=advsearchtype=Code New options complicate the situation when using JSON_UNESCAPED_UNICODE option and json_decode. [two option] json_encode JSON_NOTUTF8_SUBSTITUTE JSON_NOTUTF8_IGNORE JSON_UNESCAPED_UNICODE | JSON_NOTUTF8_SUBSTITUTE JSON_UNESCAPED_UNICODE | JSON_NOTUTF8_IGNORE json_decode JSON_NOTUTF8_SUBSTITUTE JSON_NOTUTF8_IGNORE If JSON_NOTUTF8_SUBSTITUTE is default behavior, the problem we need to consider is only JSON_NOTUTF8_IGNORE option. [one option] json_encode JSON_NOTUTF8_IGNORE JSON_UNESCAPED_UNICODE | JSON_NOTUTF8_IGNORE json_decode JSON_NOTUTF8_IGNORE [2013-07-10 13:48:35] r...@php.net Here is a proposal fo this issue https://github.com/remicollet/pecl-json-c/commit/5a499a4550d1f29f1f8eeb1b4ca0b01a33c64779 This add 2 new options to json_encode - JSON_NOTUTF8_SUBSTITUTE (name seems better, at least to me), to replace not-utf8 char with the replacement char. - JSON_NOTUTF8_IGNORE to ignore not-utf8 char (remove in escaped mode, keep without any check in unescaped mode) 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=65082 -- Edit this bug report at https://bugs.php.net/bug.php?id=65082edit=1
[PHP-BUG] Bug #65254 [NEW]: Exception not catchable when exception thrown in autoload with a namespace
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version: 5.5.0
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Exception not catchable when exception thrown in autoload with
a namespace
Description:
In the following code, the exception is not caught. In PHP 5.3, the
exception is caught, but in PHP 5.4 and PHP 5.5, the exception is not
caught. The issue only occurs when the class is in a namespace. If I
remove the namespace from the class, then the exception is caught.
Test script:
---
?php
function __autoload($class)
{
require('ns_test.php');
throw new \Exception('abcd');
}
try
{
\ns_test\test::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
ns_test.php:
?php
namespace ns_test;
class test
{
}
Expected result:
caught
Actual result:
--
Warning: Uncaught exception 'Exception' with message 'abcd' in
/tmp/test.php:6
Stack trace:
#0 /tmp/test.php(11): __autoload('ns_test\test')
#1 {main}
thrown in /tmp/test.php on line 6
Fatal error: Call to undefined method ns_test\test::go() in /tmp/test.php
on line 11
--
Edit bug report at https://bugs.php.net/bug.php?id=65254edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65254r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65254r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65254r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65254r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65254r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65254r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65254r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65254r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65254r=support
Expected behavior: https://bugs.php.net/fix.php?id=65254r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65254r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65254r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65254r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65254r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65254r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65254r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65254r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65254r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65254r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65254r=mysqlcfg
Bug #65254 [Com]: Exception not catchable when exception thrown in autoload with a namespace
Edit report at https://bugs.php.net/bug.php?id=65254edit=1
ID: 65254
Comment by: ryan dot brothers at gmail dot com
Reported by:ryan dot brothers at gmail dot com
Summary:Exception not catchable when exception thrown in
autoload with a namespace
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Upon further testing, I can reproduce the issue without using namespaces with
the following:
?php
function __autoload($class)
{
require('ns_test.php');
throw new \Exception('abcd');
}
try
{
test::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
ns_test.php:
?php
class test
{
}
Previous Comments:
[2013-07-12 18:41:12] ryan dot brothers at gmail dot com
Description:
In the following code, the exception is not caught. In PHP 5.3, the exception
is caught, but in PHP 5.4 and PHP 5.5, the exception is not caught. The issue
only occurs when the class is in a namespace. If I remove the namespace from
the class, then the exception is caught.
Test script:
---
?php
function __autoload($class)
{
require('ns_test.php');
throw new \Exception('abcd');
}
try
{
\ns_test\test::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
=
ns_test.php:
?php
namespace ns_test;
class test
{
}
Expected result:
caught
Actual result:
--
Warning: Uncaught exception 'Exception' with message 'abcd' in /tmp/test.php:6
Stack trace:
#0 /tmp/test.php(11): __autoload('ns_test\test')
#1 {main}
thrown in /tmp/test.php on line 6
Fatal error: Call to undefined method ns_test\test::go() in /tmp/test.php on
line 11
--
Edit this bug report at https://bugs.php.net/bug.php?id=65254edit=1
[PHP-BUG] Bug #65255 [NEW]: exception not catchable when thrown from autoload in an extended class
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version: 5.5.0
Package: Scripting Engine problem
Bug Type: Bug
Bug description:exception not catchable when thrown from autoload in an
extended class
Description:
This issue may be the same issue as bug 65254 that I just submitted. The
following script throws a Fatal Error rather than catching the exception.
Test script:
---
?php
function __autoload($class)
{
throw new Exception('abcd');
}
class test1 extends test2
{
public static function go()
{
}
}
try
{
test1::go();
}
catch (Exception $e)
{
echo 'caught';
exit;
}
Expected result:
caught
Actual result:
--
Fatal error: Uncaught exception 'Exception' with message 'abcd' in
/tmp/test.php:4
Stack trace:
#0 /tmp/test.php(8): __autoload('test2')
#1 {main}
thrown in /tmp/test.php on line 4
--
Edit bug report at https://bugs.php.net/bug.php?id=65255edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65255r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65255r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65255r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65255r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65255r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65255r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65255r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65255r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65255r=support
Expected behavior: https://bugs.php.net/fix.php?id=65255r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65255r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65255r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65255r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65255r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65255r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65255r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65255r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65255r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65255r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65255r=mysqlcfg
Bug #65227 [Opn-Csd]: Memory leak in gmp_cmp second parameter
Edit report at https://bugs.php.net/bug.php?id=65227edit=1 ID: 65227 Updated by: fel...@php.net Reported by:frozenf...@php.net Summary:Memory leak in gmp_cmp second parameter -Status: Open +Status: Closed Type: Bug Package:GNU MP related Operating System: Irrelevant PHP Version:unknown Block user comment: N Private report: N New Comment: Automatic comment on behalf of felipe...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=281936b29535ae095350abb274acef0ae548a431 Log: - Fixed bug #65227 (Memory leak in gmp_cmp second parameter) Previous Comments: [2013-07-09 16:25:27] frozenf...@php.net I noticed shortly after filing the bug that this issue *may* be resolved as of https://github.com/php/php- src/commit/7713b8c2ac2d8fbacaf897ff0c0a202a7b7abf49#ext/gmp/gmp.c The issue may have resulted from the lack of a free of temp_b after https://github.com/php/php- src/blob/a666285bc2488b7f7362368c388e41428610ad1d/ext/gmp/gmp.c#L1337, which would apply to all versions except 5.next [2013-07-09 16:17:47] frozenf...@php.net Description: Reporting this bug for a third party (http://www.reddit.com/r/PHP/comments/1hx7qz/what_is_going_on_here_how_do_i_fix_t his_memory/), and related to a user note (http://www.php.net/manual/en/function.gmp-cmp.php#99120). The gmp_cmp function leaks memory when a string is used as the value of the second parameter. My guess is that it relates to the way that the type is juggled in the gmp_cmp function (https://github.com/php/php-src/blob/master/ext/gmp/gmp.c#L848), where it checks the type of the second parameter to see if it's a long. It doesn't however check if the second parameter is a string, or really any other type. Test script: --- Third party's example code can be found at http://www.reddit.com/r/PHP/comments/1hx7qz/what_is_going_on_here_how_do_i_fix_this_memory/ -- Edit this bug report at https://bugs.php.net/bug.php?id=65227edit=1
Bug #65219 [Opn-Asn]: PDO/dblib not working anymore (use dbName not sent)
Edit report at https://bugs.php.net/bug.php?id=65219edit=1
ID: 65219
Updated by: fel...@php.net
Reported by:f dot marquis at of2m dot fr
Summary:PDO/dblib not working anymore (use dbName not
sent)
-Status: Open
+Status: Assigned
Type: Bug
Package:PDO related
Operating System: CentOS 6.4
PHP Version:5.4.17
-Assigned To:
+Assigned To:ssufficool
Block user comment: N
Private report: N
Previous Comments:
[2013-07-08 13:37:43] f dot marquis at of2m dot fr
Description:
All queries to our MSSQL 2008 database (PDO_dblib with freeTDS) are failing
since PHP 5.4.17 (same code)
setting freeTDS into debug mode seems to indicate that the SQL queries are not
sent to the correct database, but to 'master' database, so
queried object are not found.
FreeTDS log with PHP 5.4.17 :
...
(dblib.c:239):dblib_add_connection(0x7f001af738e0, 0x7f002be94540)
(dblib.c:4317):dbsetopt(0x7f002be93a00, 7, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 7)
(dblib.c:4317):dbsetopt(0x7f002be93a00, 17, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 17)
(dblib.c:4317):dbsetopt(0x7f002be93a00, 35, 1, -1)
(dblib.c:761):dbsetlname(0x7f002be93850, Emploi, 14)
(dblib.c:5762):dbsetuserdata(0x7f002be93a00, 0x7f002a851fa0)
(dblib.c:3196):dbcancel(0x7f002be93a00)
(query.c:2155):tds_send_cancel: not in_cancel and idle
(dblib.c:1312):dbcmd(0x7f002be93a00, SELECT col FROM table WHERE id = 1 )
...
FreeTDS log with PHP 5.4.11 (working) :
...
(dblib.c:239):dblib_add_connection(0x7fbc5d3d68e0, 0x7fbc6ec007f0)
(dblib.c:4317):dbsetopt(0x7fbc6ebffe30, 7, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 7)
(dblib.c:4317):dbsetopt(0x7fbc6ebffe30, 17, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 17)
(dblib.c:4317):dbsetopt(0x7fbc6ebffe30, 35, (null), -1)
(dblib.c:7929):dbperror(0x7fbc6ebffe30, 20176, 0)
(dblib.c:7981):20176: Called dbsetopt with parameter 3 NULL
(dblib.c:5780):dbgetuserdata(0x7fbc6ebffe30)
(dblib.c:8002):Called dbsetopt with parameter 3 NULL, client returns 2
(INT_CANCEL)
(dblib.c:1398):dbuse(0x7fbc6ebffe30, Emploi)
(dblib.c:1312):dbcmd(0x7fbc6ebffe30, use [Emploi])
(dblib.c:1319):dbcmd() bufsz = 0
(dblib.c:1369):dbsqlexec(0x7fbc6ebffe30)
(dblib.c:6862):dbsqlsend(0x7fbc6ebffe30)
(mem.c:615):tds_free_all_results()
(util.c:156):Changed query state from IDLE to QUERYING
(write.c:140):tds_put_string converting 12 bytes of use [Emploi]
(write.c:168):tds_put_string wrote 24 bytes
(util.c:156):Changed query state from QUERYING to PENDING
(net.c:741):Sending packet
...
You can see that the use [dbName] is not sent with the same way. The query is
executed in master context, and that's why it's failing.
regression from https://bugs.php.net/bug.php?id=64338 pdo_dblib can't connect
to Azure SQL
Test script:
---
$pdo = new \PDO('dblib:host=hostname;dbname=dbname', 'username', 'password');
$stmt = $pdo-query('SELECT col FROM table WHERE id = 1');
var_dump($stmt);
Expected result:
PDOStatement with the matching line from existing table
Actual result:
--
false, with this error : General SQL Server error: Check messages from the SQL
Server [208] (severity 16) = Invalid object name
--
Edit this bug report at https://bugs.php.net/bug.php?id=65219edit=1
Bug #46835 [Com]: saveHTML automatically replaces unicode letters to entities
Edit report at https://bugs.php.net/bug.php?id=46835edit=1
ID: 46835
Comment by: wahabmirjan at yahoo dot com
Reported by:kasparsj at gmail dot com
Summary:saveHTML automatically replaces unicode letters to
entities
Status: Not a bug
Type: Bug
Package:DOM XML related
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
As of July 12, 2013, almost 5 years after this problem is reported, this still
is a problem. Please fix it.
Previous Comments:
[2008-12-12 04:57:52] rricha...@php.net
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
This is the behavior exhibited from libxml2 when outputting in HTML
format
[2008-12-11 12:16:37] kasparsj at gmail dot com
Description:
DOMDocument-saveHTML replaces not only predefined entities, but also unicode
letters, like Ä, Å¡, Ä. is this also as expected or a bug?
this is related to:
http://bugs.php.net/bug.php?id=37878
Reproduce code:
---
$doc = new DOMDocument('1.0', 'UTF-8');
$doc-substituteEntities = false;
$doc-appendChild($doc-createElement('p', 'Å¡aÄeÄ'));
var_dump($doc-saveHTML());
Expected result:
pÅ¡aÄeÄ/p
Actual result:
--
pcopy;scaron;a#275;e#257;/p
--
Edit this bug report at https://bugs.php.net/bug.php?id=46835edit=1
Req #64639 [Com]: Add third parameter to nl2br
Edit report at https://bugs.php.net/bug.php?id=64639edit=1
ID: 64639
Comment by: valentiny510 at yahoo dot es
Reported by:valentiny510 at yahoo dot es
Summary:Add third parameter to nl2br
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Nikic, 2 booleans parameters for you are too many unclear boolean parameters
LOL...
Previous Comments:
[2013-05-03 08:13:28] ni...@php.net
In my eyes this is an unnecessary change. nl2br handles the common case, where
you want to have linebreaks displayed and have the code nicely formatted at the
same time. This is what nl2br does and I don't think it need to do any more.
I don't see why we should add support for incorrect usages of the function
inside pre. And in any case, if you should have need for this (for whatever
odd reason), then it is trivial to write yourself. Quite honestly I think that
preg_replace('#([\r?\n]+)#', 'br', $string) is a good bit clearer than
nl2br($string, false, true). That's just too many unclear boolean parameters.
[2013-05-03 07:01:13] octavianmarinescu at tavi dot ro
yes would be a shorter and more elegant solution
nl2br($str, false, true);
nice and clean..
[2013-04-17 19:44:35] krak...@php.net
The following patch has been added/updated:
Patch Name: nl2br_additional_parameter
Revision: 1366227875
URL:
https://bugs.php.net/patch-display.php?bug=64639patch=nl2br_additional_parameterrevision=1366227875
[2013-04-12 02:12:27] valentiny510 at yahoo dot es
Description:
The name nl2br for somebody who doesn't know php very well, suggest that
actually replace nl with br but is not true. The name of the function
function should be nl2nl+br
I think it should have a third parameter like $replace, and actually Replace
the nl with br
I have some clients who used this function inside pre with horrible result.
Anyway, I think it will be more usefull this
nl2br ($string, true/false, $replace = true/false)
than
preg_replace('#([\r?\n]+)#', 'br', $string) or
str_replace(array(\r\n, \r, \n), 'br', $string)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64639edit=1
Req #64639 [Com]: Add third parameter to nl2br
Edit report at https://bugs.php.net/bug.php?id=64639edit=1
ID: 64639
Comment by: valentiny510 at yahoo dot es
Reported by:valentiny510 at yahoo dot es
Summary:Add third parameter to nl2br
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
As additional note..
If I can have linebreaks and nicely formated text in just one function, why
don't do'it ?
I don't think is such a big deal, or should change the name to something like
addbr2nl, it will be more correct..
Previous Comments:
[2013-07-13 01:33:11] valentiny510 at yahoo dot es
Nikic, 2 booleans parameters for you are too many unclear boolean parameters
LOL...
[2013-05-03 08:13:28] ni...@php.net
In my eyes this is an unnecessary change. nl2br handles the common case, where
you want to have linebreaks displayed and have the code nicely formatted at the
same time. This is what nl2br does and I don't think it need to do any more.
I don't see why we should add support for incorrect usages of the function
inside pre. And in any case, if you should have need for this (for whatever
odd reason), then it is trivial to write yourself. Quite honestly I think that
preg_replace('#([\r?\n]+)#', 'br', $string) is a good bit clearer than
nl2br($string, false, true). That's just too many unclear boolean parameters.
[2013-05-03 07:01:13] octavianmarinescu at tavi dot ro
yes would be a shorter and more elegant solution
nl2br($str, false, true);
nice and clean..
[2013-04-17 19:44:35] krak...@php.net
The following patch has been added/updated:
Patch Name: nl2br_additional_parameter
Revision: 1366227875
URL:
https://bugs.php.net/patch-display.php?bug=64639patch=nl2br_additional_parameterrevision=1366227875
[2013-04-12 02:12:27] valentiny510 at yahoo dot es
Description:
The name nl2br for somebody who doesn't know php very well, suggest that
actually replace nl with br but is not true. The name of the function
function should be nl2nl+br
I think it should have a third parameter like $replace, and actually Replace
the nl with br
I have some clients who used this function inside pre with horrible result.
Anyway, I think it will be more usefull this
nl2br ($string, true/false, $replace = true/false)
than
preg_replace('#([\r?\n]+)#', 'br', $string) or
str_replace(array(\r\n, \r, \n), 'br', $string)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64639edit=1
