Bug #64707 [Asn->Csd]: gdImageCreateFromJpegPtrEx changes break the build
Edit report at https://bugs.php.net/bug.php?id=64707&edit=1 ID: 64707 Updated by: r...@php.net Reported by:s...@php.net Summary:gdImageCreateFromJpegPtrEx changes break the build -Status: Assigned +Status: Closed Type: Bug Package:GD related Operating System: Oracle Linux 5.9 PHP Version:5.5Git-2013-04-24 (Git) Assigned To:remi Block user comment: N Private report: N New Comment: Automatic comment on behalf of remi Revision: http://git.php.net/?p=php-src.git;a=commit;h=182fef46a989fa1f8d4ea1a7e3e22040f04e7c51 Log: Fixed bug #64707 missing declaration after dd0399f Previous Comments: [2013-04-25 03:49:21] paj...@php.net Remi, can you take a look please? [2013-04-24 23:26:02] s...@php.net Description: Compiling gd fails in 5.5 & master. My configure options are: '--with-gd' \ '--with-curl' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--enable-gd-native-ttf' The compilation error is: /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c: In function âphp_gd_gdImageCreateFromJpegPtrâ: /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:289: warning: implicit declaration of function âgdImageCreateFromJpegPtrExâ /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:289: warning: return makes pointer from integer without a cast /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c: At top level: /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:293: error: conflicting types for âgdImageCreateFromJpegPtrExâ /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:289: error: previous implicit declaration of âgdImageCreateFromJpegPtrExâ was here make: *** [ext/gd/libgd/gd_jpeg.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=64707&edit=1
Bug #64707 [Opn->Asn]: gdImageCreateFromJpegPtrEx changes break the build
Edit report at https://bugs.php.net/bug.php?id=64707&edit=1 ID: 64707 Updated by: paj...@php.net Reported by:s...@php.net Summary:gdImageCreateFromJpegPtrEx changes break the build -Status: Open +Status: Assigned Type: Bug Package:GD related Operating System: Oracle Linux 5.9 PHP Version:5.5Git-2013-04-24 (Git) -Assigned To: +Assigned To:remi Block user comment: N Private report: N New Comment: Remi, can you take a look please? Previous Comments: [2013-04-24 23:26:02] s...@php.net Description: Compiling gd fails in 5.5 & master. My configure options are: '--with-gd' \ '--with-curl' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--enable-gd-native-ttf' The compilation error is: /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c: In function âphp_gd_gdImageCreateFromJpegPtrâ: /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:289: warning: implicit declaration of function âgdImageCreateFromJpegPtrExâ /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:289: warning: return makes pointer from integer without a cast /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c: At top level: /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:293: error: conflicting types for âgdImageCreateFromJpegPtrExâ /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:289: error: previous implicit declaration of âgdImageCreateFromJpegPtrExâ was here make: *** [ext/gd/libgd/gd_jpeg.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=64707&edit=1
[PHP-BUG] Bug #64707 [NEW]: gdImageCreateFromJpegPtrEx changes break the build
From: sixd Operating system: Oracle Linux 5.9 PHP version: 5.5Git-2013-04-24 (Git) Package: GD related Bug Type: Bug Bug description:gdImageCreateFromJpegPtrEx changes break the build Description: Compiling gd fails in 5.5 & master. My configure options are: '--with-gd' \ '--with-curl' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--enable-gd-native-ttf' The compilation error is: /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c: In function âphp_gd_gdImageCreateFromJpegPtrâ: /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:289: warning: implicit declaration of function âgdImageCreateFromJpegPtrExâ /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:289: warning: return makes pointer from integer without a cast /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c: At top level: /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:293: error: conflicting types for âgdImageCreateFromJpegPtrExâ /home/cjones/php-5.5/ext/gd/libgd/gd_jpeg.c:289: error: previous implicit declaration of âgdImageCreateFromJpegPtrExâ was here make: *** [ext/gd/libgd/gd_jpeg.lo] Error 1 -- Edit bug report at https://bugs.php.net/bug.php?id=64707&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64707&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64707&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64707&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64707&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64707&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64707&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64707&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64707&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64707&r=support Expected behavior: https://bugs.php.net/fix.php?id=64707&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64707&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64707&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64707&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64707&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64707&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64707&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64707&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64707&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64707&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64707&r=mysqlcfg
Bug #53948 [Dup]: ZIP archive UTF-8 filenames problem
Edit report at https://bugs.php.net/bug.php?id=53948&edit=1 ID: 53948 Updated by: paj...@php.net Reported by:asaf at lingnu dot com Summary:ZIP archive UTF-8 filenames problem Status: Duplicate Type: Bug Package:Zip Related Operating System: linux PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Use latest pecl release to have UTF-8 support. Previous Comments: [2013-04-24 17:18:35] animelp at yahoo dot com dot ar same issue with PHP 5.2.14 [2011-12-01 13:49:14] nadavkav at gmail dot com I experience the same issue. While zipping Hebrew filenames on a CentOS 5.6 (GNU/LINUX) system with php 5.2.x and 5.3.x And then, trying to open the Zip file on a Windows XP system In Which i get ?.txt as filenames. Please see more info on the Moodle developer TRACKER system: http://tracker.moodle.org/browse/MDL-24928 [2011-09-23 11:14:13] robert at softcom dot no I also have a problem with this, so bump! [2011-06-10 23:27:47] killerloin at yahoo dot com is this problem solved yet? I really need a solution. [2011-05-30 08:49:24] mikhail dot v dot gavrilov at gmail dot com I also confirm this problem. Workaround: Helps converting to your DOS encoding. 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=53948 -- Edit this bug report at https://bugs.php.net/bug.php?id=53948&edit=1
Bug #53948 [Com]: ZIP archive UTF-8 filenames problem
Edit report at https://bugs.php.net/bug.php?id=53948&edit=1 ID: 53948 Comment by: animelp at yahoo dot com dot ar Reported by:asaf at lingnu dot com Summary:ZIP archive UTF-8 filenames problem Status: Duplicate Type: Bug Package:Zip Related Operating System: linux PHP Version:5.3.5 Block user comment: N Private report: N New Comment: same issue with PHP 5.2.14 Previous Comments: [2011-12-01 13:49:14] nadavkav at gmail dot com I experience the same issue. While zipping Hebrew filenames on a CentOS 5.6 (GNU/LINUX) system with php 5.2.x and 5.3.x And then, trying to open the Zip file on a Windows XP system In Which i get ?.txt as filenames. Please see more info on the Moodle developer TRACKER system: http://tracker.moodle.org/browse/MDL-24928 [2011-09-23 11:14:13] robert at softcom dot no I also have a problem with this, so bump! [2011-06-10 23:27:47] killerloin at yahoo dot com is this problem solved yet? I really need a solution. [2011-05-30 08:49:24] mikhail dot v dot gavrilov at gmail dot com I also confirm this problem. Workaround: Helps converting to your DOS encoding. [2011-02-18 14:02:20] paj...@php.net #51929 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=53948 -- Edit this bug report at https://bugs.php.net/bug.php?id=53948&edit=1
Bug #64704 [Opn]: Problem with ASP.NET Soap Servers
Edit report at https://bugs.php.net/bug.php?id=64704&edit=1
ID: 64704
User updated by:welfordmartin at gmail dot com
Reported by:welfordmartin at gmail dot com
Summary:Problem with ASP.NET Soap Servers
Status: Open
Type: Bug
Package:SOAP related
Operating System: All
PHP Version:5.3.24
Block user comment: N
Private report: N
New Comment:
Sorry from the work around remove the die.
Previous Comments:
[2013-04-24 17:13:49] welfordmartin at gmail dot com
Work Around for time being.
class NewSoapClient extends SoapClient{
public function __doRequest($request, $location, $action, $version,
$one_way = 0) {
preg_match_all("/xmlns:ns([0-9*])=\"(.[^\\\"]*)\\\"/", $request, $env);
foreach($env[0] as $key => $val){
$request = str_replace($val, "", $request);
preg_match_all("/ $v){
$request = str_replace($v, "<".$test[1][$k]."
xmlns=\"".$env[2][$k]."\"", $request);
$request = str_replace(str_replace("<", "
ASP.NET uses
Please look at "The Test Scripts" for the problem that occures these are not
the
php code but the payload generated by SoapClient and the manual modifications i
had to to to get the code to work on my REST Testing client.
Test script:
---
Working:
http://pb.mgawow.co.uk/yvxCQe2S
Not Working PHP SoapClient Generated:
http://pb.mgawow.co.uk/r9xjaEW4
Expected result:
Working API Call
Actual result:
--
Fails causes a 500 error on remote server called
--
Edit this bug report at https://bugs.php.net/bug.php?id=64704&edit=1
Bug #64704 [Opn]: Problem with ASP.NET Soap Servers
Edit report at https://bugs.php.net/bug.php?id=64704&edit=1
ID: 64704
User updated by:welfordmartin at gmail dot com
Reported by:welfordmartin at gmail dot com
Summary:Problem with ASP.NET Soap Servers
Status: Open
Type: Bug
Package:SOAP related
Operating System: All
PHP Version:5.3.24
Block user comment: N
Private report: N
New Comment:
Work Around for time being.
class NewSoapClient extends SoapClient{
public function __doRequest($request, $location, $action, $version,
$one_way = 0) {
preg_match_all("/xmlns:ns([0-9*])=\"(.[^\\\"]*)\\\"/", $request, $env);
foreach($env[0] as $key => $val){
$request = str_replace($val, "", $request);
preg_match_all("/ $v){
$request = str_replace($v, "<".$test[1][$k]."
xmlns=\"".$env[2][$k]."\"", $request);
$request = str_replace(str_replace("<", "
ASP.NET uses
Please look at "The Test Scripts" for the problem that occures these are not
the
php code but the payload generated by SoapClient and the manual modifications i
had to to to get the code to work on my REST Testing client.
Test script:
---
Working:
http://pb.mgawow.co.uk/yvxCQe2S
Not Working PHP SoapClient Generated:
http://pb.mgawow.co.uk/r9xjaEW4
Expected result:
Working API Call
Actual result:
--
Fails causes a 500 error on remote server called
--
Edit this bug report at https://bugs.php.net/bug.php?id=64704&edit=1
[PHP-BUG] Bug #64705 [NEW]: errorInfo property of PDOException is null when PDO::__construct() fails
From: christian dot lawrence at calorieking dot com
Operating system:
PHP version: 5.3.24
Package: PDO related
Bug Type: Bug
Bug description:errorInfo property of PDOException is null when
PDO::__construct() fails
Description:
PDO::__construct() will always throw a PDOException if the connection fails
regardless of which PDO::ATTR_ERRMODE is currently set. The PDOException
has a public property $errorInfo which corresponds to PDO::errorInfo() or
PDOStatement::errorInfo().
When PDO::__construct() throws a PDOException say, because of a database
server issue, the public property PDOException::$errorInfo is set to NULL
and the return value from PDOException::getCode() is not the expected
string SQLSTATE error code.
I would have expected a non-NULL PDOException::$errorInfo to be set when
the exception is caught.
Test script:
---
errorInfo);
var_dump($e->getCode());
var_dump($e->getMessage());
}
?>
Expected result:
array(3) {
[0] =>
string(5) "08006"
[1] =>
int(7)
[2] =>
string(53) "FATAL: password authentication failed for user "foo""
}
string(5) "08006"
string(73) "SQLSTATE[08006] [7] FATAL: password authentication failed for
user "foo""
Actual result:
--
NULL
int(7)
string(73) "SQLSTATE[08006] [7] FATAL: password authentication failed for
user "foo""
--
Edit bug report at https://bugs.php.net/bug.php?id=64705&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64705&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64705&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64705&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64705&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64705&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64705&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64705&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64705&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64705&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64705&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64705&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64705&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64705&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64705&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64705&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64705&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64705&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64705&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64705&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64705&r=mysqlcfg
Bug #64704 [Com]: Problem with ASP.NET Soap Servers
Edit report at https://bugs.php.net/bug.php?id=64704&edit=1 ID: 64704 Comment by: welfordmartin at gmail dot com Reported by:welfordmartin at gmail dot com Summary:Problem with ASP.NET Soap Servers Status: Open Type: Bug Package:SOAP related Operating System: All PHP Version:5.3.24 Block user comment: N Private report: N New Comment: Recommended Fix: It would be nice if there was an option in setting up the SoapClient that tells it to use inline xmlns instead of in Envelope namespacing Previous Comments: [2013-04-24 16:07:57] welfordmartin at gmail dot com Description: This might want changing to a Feature Request instead of bug but I'm not sure. There is a problem in ASP.NET SOAP Server that for some reason does not support using the Envelope xmlns:ns stuff inside the soap:header this is how php SoapClient works ASP.NET uses Please look at "The Test Scripts" for the problem that occures these are not the php code but the payload generated by SoapClient and the manual modifications i had to to to get the code to work on my REST Testing client. Test script: --- Working: http://pb.mgawow.co.uk/yvxCQe2S Not Working PHP SoapClient Generated: http://pb.mgawow.co.uk/r9xjaEW4 Expected result: Working API Call Actual result: -- Fails causes a 500 error on remote server called -- Edit this bug report at https://bugs.php.net/bug.php?id=64704&edit=1
[PHP-BUG] Bug #64704 [NEW]: Problem with ASP.NET Soap Servers
From: welfordmartin at gmail dot com Operating system: All PHP version: 5.3.24 Package: SOAP related Bug Type: Bug Bug description:Problem with ASP.NET Soap Servers Description: This might want changing to a Feature Request instead of bug but I'm not sure. There is a problem in ASP.NET SOAP Server that for some reason does not support using the Envelope xmlns:ns stuff inside the soap:header this is how php SoapClient works ASP.NET uses Please look at "The Test Scripts" for the problem that occures these are not the php code but the payload generated by SoapClient and the manual modifications i had to to to get the code to work on my REST Testing client. Test script: --- Working: http://pb.mgawow.co.uk/yvxCQe2S Not Working PHP SoapClient Generated: http://pb.mgawow.co.uk/r9xjaEW4 Expected result: Working API Call Actual result: -- Fails causes a 500 error on remote server called -- Edit bug report at https://bugs.php.net/bug.php?id=64704&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64704&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64704&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64704&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64704&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64704&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64704&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64704&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64704&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64704&r=support Expected behavior: https://bugs.php.net/fix.php?id=64704&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64704&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64704&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64704&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64704&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64704&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64704&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64704&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64704&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64704&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64704&r=mysqlcfg
Bug #54975 [Com]: php make
Edit report at https://bugs.php.net/bug.php?id=54975&edit=1
ID: 54975
Comment by: mzeynalli at gmail dot com
Reported by:hzhihu at gmail dot com
Summary:php make
Status: No Feedback
Type: Bug
Package:*General Issues
Operating System: fedora15
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Setting the LD_LIBRARY_PATH with /usr/lib value before trying to compile php
5.3.24 solved this problem. Of course there could be another options to solve
this
issue.
export LD_LIBRARY_PATH=/usr/lib
Previous Comments:
[2013-02-18 00:34:52] 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-08-20 19:38:03] balaurulmaresipufos at yahoo dot com
open("/usr/share/locale/en/LC_MESSAGES/make.mo", O_RDONLY) = -1 ENOENT (No such
file or directory)
write(2, "make: ", 6make: ) = 6
write(2, "*** [ext/phar/phar.phar] Error 1"..., 34*** [ext/phar/phar.phar]
Error 127) = 34
write(2, "\n", 1
) = 1
rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM XCPU XFSZ], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
chdir("/root/setup/php-5.3.15") = 0
close(1)= 0
exit_group(2)
[2011-06-03 03:48:53] fel...@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2011-06-02 05:15:31] hzhihu at gmail dot com
Description:
Generating phar.php
/home/charles/ä¸è½½/php-5.3.3/sapi/cli/php: symbol lookup error:
/home/charles/ä¸è½½/php-5.3.3/sapi/cli/php: undefined symbol: client_errors
make: *** [ext/phar/phar.php] é误 127
--
Edit this bug report at https://bugs.php.net/bug.php?id=54975&edit=1
Bug #61706 [Com]: escapeshellarg behaves inconsistently depending on shell
Edit report at https://bugs.php.net/bug.php?id=61706&edit=1 ID: 61706 Comment by: phpbugs at personal dot formauri dot es Reported by:phpbugs at personal dot formauri dot es Summary:escapeshellarg behaves inconsistently depending on shell Status: Open Type: Bug Package:Program Execution Operating System: Linux, Unix, maybe OSX, NOT msw PHP Version:5.4Git-2012-04-12 (Git) Block user comment: N Private report: N New Comment: Patch here: http://www.formauri.es/personal/pgimeno/temp/escapeshellarg-bug-61706.patch Previous Comments: [2013-04-24 11:39:39] phpbugs at personal dot formauri dot es For extra background, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550399 Unlike what I thought at first, it seems to affect the shell's built-in echo command specifically. As noted in that bug, it also affects shells other than dash, including posh and mksh. I've had the problem with zsh as well. And as noted in that bug, dash is the default shell in many systems, and also in Ubuntu (see https://bugs.launchpad.net/ubuntu/+source/dash/+bug/259671 ). Debian also offers to install posh as the default /bin/sh. The consensus seems to be that that is not a bug in the shell, because the result of using backslashes in the shell's builtin echo is implementation-defined, and therefore it's PHP's responsibility to escape them properly, e.g. in the suggested way. On a different topic, one advantage of using the method of switching mode depending on the runs of should-be-escaped/should-not-be-escaped characters, as in the PHP example function shown above, is that the temporary storage requirement is reduced from 4n+2 as is now, or ~4 times the length, to ceil(5n/2), or ~2.5 times the length. That's because the worst case for the current behavior is a sequence of single-quotes which is written as ''\'''\'''\''...'\''' and the worst case for the proposed behaviour is alternating escaped/non-escaped characters as in 'x'\\'x'\\'x'\\...'x', therefore every 2 characters are turned into 5 with possibly an extra character at the end. [2012-04-13 00:51:55] zhanglijiu at gmail dot com My result is \\ my system is Mac OS SHould be bash [2012-04-12 22:22:04] phpbugs at personal dot formauri dot es Description: Depending on the shell, for shell internal commands the backslashes within single quotes are interpreted as escapes or are used verbatim. For example, in bash and in busybox: $ echo '\\' \\ But in dash: $ echo '\\' \ dash is frequently set as the default /bin/sh so this is a problem. More so since some programs need to get their input from stdin and therefore they need the use of 'echo' for input not coming from a file or being input from the console. To work around the backslash inconsistency among shells, backslashes should receive special treatment as quotes do, e.g. translate \ to '\\'. I was tempted of sending this as a security issue, but the scenarios where security could be in risk are too improbable for it to be a serious security concern. Ideally though, no unnecessary quotes should be used in the output string, e.g. escapeshellarg should convert '''abc\\'\ into \'\'\''abc'\'\\. Currently it converts '''abc\\'\ into ''\'''\'''\''abc\\'\''\' which exhibits the bug and is unnecessarily large. For backwards compatibility, maybe an extra argument should be added to also quote backslashes and use a new method of quoting. Here is a PHP function that implements the suggestions here, using strspn and strcspn to grab the longest spans that it can "eat" at a time of each kind (characters to escape / characters not to escape): http://www.formauri.es/personal/pgimeno/temp/sh_escape.phps (includes test suite). Test script: --- Expected result: No matter the shell: \\ Actual result: -- If your /bin/sh is dash: \ If your /bin/sh is busybox: \\ Other shells: ?? -- Edit this bug report at https://bugs.php.net/bug.php?id=61706&edit=1
Bug #61706 [Com]: escapeshellarg behaves inconsistently depending on shell
Edit report at https://bugs.php.net/bug.php?id=61706&edit=1 ID: 61706 Comment by: phpbugs at personal dot formauri dot es Reported by:phpbugs at personal dot formauri dot es Summary:escapeshellarg behaves inconsistently depending on shell Status: Open Type: Bug Package:Program Execution Operating System: Linux, Unix, maybe OSX, NOT msw PHP Version:5.4Git-2012-04-12 (Git) Block user comment: N Private report: N New Comment: For extra background, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550399 Unlike what I thought at first, it seems to affect the shell's built-in echo command specifically. As noted in that bug, it also affects shells other than dash, including posh and mksh. I've had the problem with zsh as well. And as noted in that bug, dash is the default shell in many systems, and also in Ubuntu (see https://bugs.launchpad.net/ubuntu/+source/dash/+bug/259671 ). Debian also offers to install posh as the default /bin/sh. The consensus seems to be that that is not a bug in the shell, because the result of using backslashes in the shell's builtin echo is implementation-defined, and therefore it's PHP's responsibility to escape them properly, e.g. in the suggested way. On a different topic, one advantage of using the method of switching mode depending on the runs of should-be-escaped/should-not-be-escaped characters, as in the PHP example function shown above, is that the temporary storage requirement is reduced from 4n+2 as is now, or ~4 times the length, to ceil(5n/2), or ~2.5 times the length. That's because the worst case for the current behavior is a sequence of single-quotes which is written as ''\'''\'''\''...'\''' and the worst case for the proposed behaviour is alternating escaped/non-escaped characters as in 'x'\\'x'\\'x'\\...'x', therefore every 2 characters are turned into 5 with possibly an extra character at the end. Previous Comments: [2012-04-13 00:51:55] zhanglijiu at gmail dot com My result is \\ my system is Mac OS SHould be bash [2012-04-12 22:22:04] phpbugs at personal dot formauri dot es Description: Depending on the shell, for shell internal commands the backslashes within single quotes are interpreted as escapes or are used verbatim. For example, in bash and in busybox: $ echo '\\' \\ But in dash: $ echo '\\' \ dash is frequently set as the default /bin/sh so this is a problem. More so since some programs need to get their input from stdin and therefore they need the use of 'echo' for input not coming from a file or being input from the console. To work around the backslash inconsistency among shells, backslashes should receive special treatment as quotes do, e.g. translate \ to '\\'. I was tempted of sending this as a security issue, but the scenarios where security could be in risk are too improbable for it to be a serious security concern. Ideally though, no unnecessary quotes should be used in the output string, e.g. escapeshellarg should convert '''abc\\'\ into \'\'\''abc'\'\\. Currently it converts '''abc\\'\ into ''\'''\'''\''abc\\'\''\' which exhibits the bug and is unnecessarily large. For backwards compatibility, maybe an extra argument should be added to also quote backslashes and use a new method of quoting. Here is a PHP function that implements the suggestions here, using strspn and strcspn to grab the longest spans that it can "eat" at a time of each kind (characters to escape / characters not to escape): http://www.formauri.es/personal/pgimeno/temp/sh_escape.phps (includes test suite). Test script: --- Expected result: No matter the shell: \\ Actual result: -- If your /bin/sh is dash: \ If your /bin/sh is busybox: \\ Other shells: ?? -- Edit this bug report at https://bugs.php.net/bug.php?id=61706&edit=1
Bug #62639 [Asn]: XML structure broken
Edit report at https://bugs.php.net/bug.php?id=62639&edit=1 ID: 62639 Updated by: larue...@php.net Reported by:alexshock at yandex dot ru Summary:XML structure broken Status: Assigned Type: Bug Package:SimpleXML related Operating System: debian 6.0.5 PHP Version:5.4.5 Assigned To:acurioso Block user comment: N Private report: N New Comment: I think we should revert the previous fix at now, since this new bug is more critical than the previous one. and I think the key problem there is that we can not tell iterating from convert_to_array in the sxe_get_prop_hash without that, I don't think we can get a good fix for the 034.phpt Previous Comments: [2013-02-18 21:21:48] sala...@php.net Related To: Bug #62203 [2012-07-30 01:57:05] willfi...@php.net I think that would make more sense. Thanks, Andrew. [2012-07-30 00:58:13] acuri...@php.net I can confirm that reverting that patch does fix the bug; however, it causes the original test to fail again: = FAILED TEST SUMMARY - SimpleXML: cast to array [ext/simplexml/tests/034.phpt] Bug #51615 (PHP crash with wrong HTML in SimpleXML) [ext/simplexml/tests/bug51615.phpt] = See: ext/simplexml/tests/034.phpt for more information. Ignore bug51615.phpt for now. That is just a side effect of test 34. I would actually prefer if I could take the first stab at this bug myself since it was clearly introduced in my code. I'd be hesitate to just revert the changes since that would break test 34. [2012-07-29 23:44:17] acuri...@php.net After reverting locally do all the unit test cases for SimpleXML still pass? This was not the case prior to the patch (one test was failing). I'll work on reverting the change locally on my end tonight and see if I can reproduce the bug and fix. [2012-07-29 23:16:31] willfi...@php.net Andrew - Would you mind taking a look at this? I reverted 1e3b32c777829f61fa9a18278e0647e9112d96ea locally, and array typecasting works fine without the patch. Also, this patch causes the last child in an element to be skipped in the case pointed out in this report. I wanted to get your input before I move forward with any changes. 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=62639 -- Edit this bug report at https://bugs.php.net/bug.php?id=62639&edit=1
