Bug #65238 [Opn->Nab]: On empty files, SplFileObject::fgets() returns not FALSE but EMPTY STRING

[ab]

Edit report at https://bugs.php.net/bug.php?id=65238&edit=1

 ID: 65238
 Updated by: a...@php.net
 Reported by:ryosuke_i_628 at yahoo dot co dot jp
 Summary:On empty files, SplFileObject::fgets() returns not
 FALSE but EMPTY STRING
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:SPL related
 Operating System:   Windows
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The docs:

Returns a string containing the next line from the file, or FALSE on error.

How it flows:

1. iteration
$file->eof() -> false
echo $file->fgets(); -> ""
2. iteration
$file->eof() -> true

You would have false/exception if say you delete the file between ->eof() and -
>fgets(), but without an error the flow is pretty matching. If you think your 
example should go onto the docs page, please feel free to extend it.


Previous Comments:

[2013-07-10 17:46:41] ryosuke_i_628 at yahoo dot co dot jp

Description:

I don't know whether this is a bug or a documentation problem.

In SplFileObject::fgets documentation,

Example is shown as following:
eof()) {
echo $file->fgets();
}
?>

But this should be:
fgets("file.txt")) !== "") {
echo $buffer;
}
?>

I show you the test script.

Test script:
---
eof()) {
$arr[] = $file->fgets();
}
var_dump($arr);

Expected result:

array(1) {
  [0]=>
  bool(false)
}

# Actually, this substitution should not occurr.

Actual result:
--
array(1) {
  [0]=>
  string(0) ""
}

# I think this can give us lots confusion.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65238&edit=1

Req #65082 [Asn]: json_encode's option for replacing ill-formd byte sequences with substitute cha

[masakielastic at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=65082&edit=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:

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


Previous Comments:

[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=PHP&q=json_encode&ref=advsearch&type=Code
https://github.com/search?l=PHP&q=json_decode&ref=advsearch&type=Code

The same problem can be seen in htmlspecialchars.

https://github.com/search?l=PHP&q=htmlspecialchars&ref=advsearch&type=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)


[2013-06-21 07:26:33] ni...@php.net

It's currently possible to get a partial output using 
JSON_PARTIAL_OUTPUT_ON_ERROR. This will replace invalid UTF8 strings with NULL 
though. It probably would make sense to have an alternative option that inserts 
the substitution character.


[2013-06-21 05:31:34] masakielastic at gmail dot com

Description:

json_encode returns false if the string contains ill-formed byte 
sequences. It is hard to find the problem since a lot of web applications don't 
expect the existence of ill-formed byte sequences. The one example is Symfony's 
JsonResponse class.

https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundat
ion/JsonResponse.php#L83

Introducing json_encode's option for replacing ill-formd byte sequences with 
substitute characters (such as U+FFFD) save writing the logic.

function json_encode2($value, $options, $depth)
{
if (is_scalar($value)) {
return json_encode($value, $options, $depth);
}

$value2 = [];

foreach ($value as $key => $elm) {

$value2[str_scrub($key)] = str_scrub($elm);

}

return json_encode($value2, $options, $depth);
}


// https://bugs.php.net/bug.php?id=65081
function str_scrub($str, $encoding = 'UTF-8')
{
return htmlspecialchars_decode(htmlspecialchars($str, ENT_SUBSTITUTE, 
$encoding));
}

The precedent example is htmlspecialchars's ENT_SUBSTITUTE option which was 
introduced 
in PHP 5.4. json_encode shares the part of logic used such as 
php_next_utf8_char 
by htmlspecialchars since PHP 5.5.

https://github.com/php/php-src/blob/master/ext/json/json.c#L369

Another reason for introducing the option is existence of JsonSerializable 
interface.

Accessing jsonSerialize method's values come from private properties is hard 
or impossbile.

The one of names of candiates for the option is JSON_SUBSTITUTE s

Req #65082 [Asn]: json_encode's option for replacing ill-formd byte sequences with substitute cha

[masakielastic at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=65082&edit=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:

Hi, I fixed my patch and added test case for json_decode.


Previous Comments:

[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=PHP&q=json_encode&ref=advsearch&type=Code
https://github.com/search?l=PHP&q=json_decode&ref=advsearch&type=Code

The same problem can be seen in htmlspecialchars.

https://github.com/search?l=PHP&q=htmlspecialchars&ref=advsearch&type=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)


[2013-06-21 07:26:33] ni...@php.net

It's currently possible to get a partial output using 
JSON_PARTIAL_OUTPUT_ON_ERROR. This will replace invalid UTF8 strings with NULL 
though. It probably would make sense to have an alternative option that inserts 
the substitution character.




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=65082&edit=1

Bug #65226 [Com]: chroot() does not get enabled

[josh at servebyte dot com]

Edit report at https://bugs.php.net/bug.php?id=65226&edit=1

 ID: 65226
 Comment by: josh at servebyte dot com
 Reported by:josh at servebyte dot com
 Summary:chroot() does not get enabled
 Status: Closed
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Debian 7
 PHP Version:5.5.0
 Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

I tested both the PHP 5.4 and 5.5 git branches and can confirm that this is 
fixed.

I used this command for testing: ./configure --prefix=/opt/php/5.x 

Thank you very much!


Previous Comments:

[2013-07-10 22:56:13] a...@php.net

Please test on 5.4+ git. You still have to disable any SAPI other than 
CLI/CGI/embed for that to work.


[2013-07-10 22:52:59] a...@php.net

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=2acc38627092123ac462f3a23780bf887bf69286
Log: Fixed bug #65226 chroot() does not get enabled


[2013-07-10 19:18:27] josh at servebyte dot com

Adding "--enable-cgi --enable-cli" to configure didn't change anything. 

$PHP_SAPI is in A LOT of files. I don't know where to start looking for it. :(


[2013-07-10 17:40:46] a...@php.net

That's clear that you can trick it to out the desired define :) ... 

Ok, i also see 'checking for chroot ... yes', but i do --enable-cgi 
--enable-cli 
too, not just ./configure . That might be the difference. Haven't looked where 
PHP_SAPI is set, you could debug it.

config.nice is created once ./configure was run, so you don't have to type all 
the options again.


[2013-07-10 17:24:46] josh at servebyte dot com

There's no file called config.nice in the 5.5.0 tar?

./configure | grep chroot
checking for chroot... yes

I can get it working by editing the configure file and commenting these lines 
like so;

if test "$PHP_SAPI" = "cgi" || test "$PHP_SAPI" = "cli" || test "$PHP_SAPI" = $
$as_echo "#define ENABLE_CHROOT_FUNC 1" >>confdefs.h
fi

to 

#if test "$PHP_SAPI" = "cgi" || test "$PHP_SAPI" = "cli" || test "$PHP_SAPI" = $
$as_echo "#define ENABLE_CHROOT_FUNC 1" >>confdefs.h
#fi

The variable $PHP_SAPI is set to "none" so it seems to be a configure bug of 
some sort.




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=65226


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65226&edit=1

Req #60524 [Com]: specify temp dir by php.ini

[mail+bugs dot php dot net at kazik dot de]

Edit report at https://bugs.php.net/bug.php?id=60524&edit=1

 ID: 60524
 Comment by: mail+bugs dot php dot net at kazik dot de
 Reported by:mail+bugs dot php dot net at kazik dot de
 Summary:specify temp dir by php.ini
 Status: Closed
 Type:   Feature/Change Request
 Package:Filesystem function related
 Operating System:   *
 PHP Version:*
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The 5.5's pull request is here:
https://github.com/php/php-src/pull/262

It should be easy to patch 5.4 and 5.3 with that or a slightly modified version 
(there a older patches for 5.3 and 5.4 available).

Whether this should be backported or not is not for me to decide.

So, feel free to port.


Previous Comments:

[2013-07-09 12:07:46] mail at tomsommer dot dk

Any chance of getting this backported to 5.3 and 5.4?


[2013-01-29 06:58:31] s...@php.net

The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

merged into 5.5 as 475a644bd84c071da04b4272b829a187a2c6d282


[2012-05-10 15:27:56] mail+bugs dot php dot net at kazik dot de

Added patch for 5.3.4, of course (and not 4.3.4)


[2012-05-10 15:25:59] mail+bugs dot php dot net at kazik dot de

Added patch for 4.3.4


[2011-12-14 14:33:53] mail+bugs dot php dot net at kazik dot de

Description:

This patch (against 5.3.8) adds a new php.ini directive to specify the path for 
the temporary files.

Why:
If, for security reasons, every user is only allowed to use their own home 
directories, it's not possible to specify their own tmp dir (e.g. 
"/home/user/tmp"). The directory for uploading and session can already be 
specified. Since all users may use the same php.ini (different [HOST=domain] 
entries, [1]) it's not possible to set the environment TMPDIR variable, because 
it would affect all users.

[1] http://php.net/manual/en/ini.sections.php

Test script:
---
ini: system_tmp_dir = "/home/user/tmp"

php: var_export(sys_get_temp_dir());

Expected result:

'/home/user/tmp'

Actual result:
--
'/tmp' (depends on system configuration)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60524&edit=1

Bug #65237 [Nab]: Array Equality Bug

[jchan at malwarebytes dot org]

Edit report at https://bugs.php.net/bug.php?id=65237&edit=1

 ID: 65237
 User updated by:jchan at malwarebytes dot org
 Reported by:jchan at malwarebytes dot org
 Summary:Array Equality Bug
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   OSX & Linux Tested
 PHP Version:5.3.26
 Block user comment: N
 Private report: N

 New Comment:

@a...@php.net - ah, you're right. Thank you.


Previous Comments:

[2013-07-11 06:53:19] a...@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

array('apple','banana') == array(1 => 'banana',2=>'apple')

is the same as

array(0 => 'apple', 1 => 'banana') == array(1 => 'banana',2=>'apple')

So the doc won :)


[2013-07-10 17:32:11] jchan at malwarebytes dot org

Description:

When comparing 2 arrays in an if statement, array equality according to the 
documentation (http://www.php.net/manual/en/language.operators.array.php) does 
not 
work. According to the docs, order should not matter, but when comparing 2 
arrays 
directly it does.

Test script:
---
http://www.php.net/manual/en/language.operators.array.php

$a = array("apple", "banana");
$b = array(1 => "banana", "0" => "apple");


## WORKS ##
var_dump($a == $b); // bool(true)
var_dump($a === $b); // bool(false)
var_dump(array("apple", "banana") == array(1 => "banana", "0" => "apple")); // 
bool(true)


## FAILS? ##
if (array('apple','banana') == array(1 => 'banana',2=>'apple'))
   echo "they are equal.\n";
else
   echo "They are not equal.\n"; // this is the response I get

## yet if I do:
if ($a == $b)
   echo "they are equal.\n"; // this is the response I get...
else 
   echo "They are not equal.\n";



?>

Expected result:

bool(true)
bool(false)
bool(true)
they are equal.
they are equal.

Actual result:
--
bool(true)
bool(false)
bool(true)
They are not equal.
they are equal.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65237&edit=1

[PHP-BUG] Req #65244 [NEW]: function_exist() returns false when using imported namespace alias

[strategycon at yahoo dot com]

From: strategycon at yahoo dot com
Operating system: Ubuntu
PHP version:  5.3Git-2013-07-11 (snap)
Package:  Reflection related
Bug Type: Feature/Change Request
Bug description:function_exist() returns false when using imported namespace 
alias

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 bug report at https://bugs.php.net/bug.php?id=65244&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65244&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65244&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65244&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65244&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65244&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65244&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65244&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65244&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65244&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65244&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65244&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65244&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65244&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65244&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65244&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65244&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65244&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65244&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65244&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65244&r=mysqlcfg

[PHP-BUG] Bug #65245 [NEW]: Segmentation fault when compiling PHP with XSL enabled

[fra dot nospam dot nk at gmx dot de]

From: fra dot nospam dot nk at gmx dot de
Operating system: AIX
PHP version:  5.3.27
Package:  Compile Failure
Bug Type: Bug
Bug description:Segmentation fault when compiling PHP with XSL enabled

Description:

Similar to bug #51216, a PHP build with "--with-xsl" unexpectedly ends with
the intermediately build "sapi/cli/php" crashing with a segmentation fault
when called in the "Generating phar.php" build step. The environment is:

AIX: 6100-08-01-1245
xlC: 11.01..0009
php: 5.3.26
libxml2: 2.9.1
libxslt: 1.1.28

Disabling "--with-xsl" produces a successful PHP build though.

Test script:
---
Build PHP with the above platform/versions and the "--with-xsl" configure
option.

Expected result:

Successful PHP build

Actual result:
--
$ dbx sapi/cli/php core 
Type 'help' for help.
[using memory image in core]
reading symbolic information ...

Segmentation fault in exsltRegisterAll at 0xd2dfa2b0 ($t1)
0xd2dfa2b0 (exsltRegisterAll+0x88) 800c lwz   r0,0x0(r12)
(dbx) where
exsltRegisterAll() at 0xd2dfa2b0
exsltRegisterAll() at 0xd2dfa234
zm_startup_xsl() at 0x104c2400
zend_startup_module_ex@AF200_118() at 0x100287a0
zend_hash_apply() at 0x1002c814
zend_startup_modules() at 0x100261cc
php_module_startup() at 0x1012f150
php_cli_startup() at 0x10002314
php_cli.main() at 0x16a0


$ gdb sapi/cli/php core
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

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 "powerpc-ibm-aix5.1.0.0".
For bug reporting instructions, please see:
...
Reading symbols from /xxx/build-cli/sapi/cli/php...(no debugging symbols
found)...done.
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
#0  0xd2dfa2b0 in ?? ()
(gdb) bt
#0  0xd2dfa2b0 in ?? ()
#1  0xd2dfa238 in ?? ()
#2  0x104c2404 in zm_startup_xsl ()
#3  0x100287a4 in zend_startup_module_ex@AF200_118 ()
#4  0x1002c818 in zend_hash_apply ()
#5  0x100261d0 in zend_startup_modules ()
#6  0x1012f154 in php_module_startup ()
#7  0x10002318 in php_cli_startup ()
#8  0x16a4 in main ()

-- 
Edit bug report at https://bugs.php.net/bug.php?id=65245&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65245&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65245&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65245&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65245&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65245&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65245&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65245&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65245&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65245&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65245&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65245&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65245&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65245&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65245&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65245&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65245&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65245&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65245&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65245&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65245&r=mysqlcfg

Bug #65240 [Nab]: Return code not updating exit status

[rkelley at transperfect dot com]

Edit report at https://bugs.php.net/bug.php?id=65240&edit=1

 ID: 65240
 User updated by:rkelley at transperfect dot com
 Reported by:rkelley at transperfect dot com
 Summary:Return code not updating exit status
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

I see in the manual where it say return will end the execution if it is in the 
top level function or a script but it does not state what it does with the 
return value explicit for a script. When filling this bug I referred to C++ 
where a return 1 in the main function would result in a exit code of 1 being 
seen on the shell.


Previous Comments:

[2013-07-11 06:06:29] larue...@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

php -r 'exit(0);' ; echo $?


[2013-07-10 20:14:54] rkelley at transperfect dot com

Description:

When the top level function does a return, that code is not reflected in the 
exit status.

Test script:
---
php -r 'return(1);' ; echo $?



Expected result:

1

Actual result:
--
0






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65240&edit=1

Bug #64836 [Com]: segfault in softmagic.c

[joschi at tollwerk dot de]

Edit report at https://bugs.php.net/bug.php?id=64836&edit=1

 ID: 64836
 Comment by: joschi at tollwerk dot de
 Reported by:r dot biegel at gmx dot at
 Summary:segfault in softmagic.c
 Status: Feedback
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Gentoo Linux
 PHP Version:5.4.15
 Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

I can confirm the issue on an x86_64 hardened Gentoo box with both PHP 5.4.17 
as well as PHP 5.5.0. It's not only the TYPO3 upgrade wizard that is failing, 
but also several TYPO3 backend modules (probably all the ones involving 
thumbnail generation) as well as the frontend (in my case at least).

As stated above, downgrading sys-apps/file to version 5.11 solves the issue for 
me as well.


Previous Comments:

[2013-07-09 22:09:18] a...@php.net

Thanks staying on this guys. Reading the linked ticket:

"Simply removing (and thus disabling file) /usr/share/misc/magic.mgc "fixes" 
issues 
with Mediawiki"

That could be a plausible explanation why PHP could fail, not sure about crash. 
As 
PHP uses a compiled in magic file which is strongly recommended to use (so no 
external file loading). However that explanation wouldn't exactly match with 
what 
"r dot biegel at gmx dot at" told earlier

"PHP Versions 5.3.25, 5.4.13, 5.4.14, 5.4.15 and 5.5.0_rc2 all segfault for 
me." 

where by 5.3 didn't become any libmagic upgrades since long. That fact makes me 
really confused, as that would mean even without upgrade the constellation of 
apache svn module and php would cause crash. 5.3 has libmagic 5.11 or older if 
i 
don't err.

And this is anyway something i can't reproduce compiling all the stuff 
manually. 
@r.biegel - if downgrading libmagic on your gentoo system works, i would close 
this 
ticket with the status "mystic" :)

Thanks


[2013-07-09 08:46:08] sabel at altmuehlnet dot de

https://bugs.gentoo.org/show_bug.cgi?id=471682

Downgrading sys-apps/file to version 5.11 solved the issue for me.


[2013-07-08 22:09:02] sabel at altmuehlnet dot de

I have the same issue on two different systems with two different applications 
(ownCloud and Roundcubemail).
Disabling (removing -D SVN) the svn module fixes the problem...
Any news on that issue?


[2013-06-10 17:23:14] r dot biegel at gmx dot at

USE=nss doesn't work for me. Seems to be another problem, sorry.


[2013-06-10 16:06:21] mah at everybody dot org

Someone posting on this problem on the Gentoo forums 
(https://forums.gentoo.org/viewtopic-p-7260284.html) said that they fixed this 
(or a similar problem) by adding USE=nss for apr-utils.




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=64836


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64836&edit=1

[PHP-BUG] Bug #65247 [NEW]: php.exe crashes when opcache.enable_cli=1

[me at laurinkeithdavis dot com]

From: me at laurinkeithdavis dot com
Operating system: Windows 7 x64
PHP version:  5.5.0
Package:  Reproducible crash
Bug Type: Bug
Bug description:php.exe crashes when opcache.enable_cli=1

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 bug report at https://bugs.php.net/bug.php?id=65247&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65247&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65247&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65247&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65247&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65247&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65247&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65247&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65247&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65247&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65247&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65247&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65247&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65247&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65247&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65247&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65247&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65247&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65247&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65247&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65247&r=mysqlcfg

Bug #49139 [Com]: proc_open requires double quotes

[ku at digitaldolphins dot jp]

Edit report at https://bugs.php.net/bug.php?id=49139&edit=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.0>php -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:

 array('pipe', 'r'),
   1 => array('pipe', 'w'),
   2 => array('pipe', 'w')
);

$resource = proc_open($cmd, $des, $pipes, null, $_ENV);
var_dump(stream_get_contents($pipes[0]));
var_dump(stream_get_contents($pipes[1]));
var_dump

Bug #65247 [Opn->Fbk]: php.exe crashes when opcache.enable_cli=1

[ab]

Edit report at https://bugs.php.net/bug.php?id=65247&edit=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=65247&edit=1