Bug #53963 [Asn->Csd]: Failed to decode, yet json_last_error() is JSON_ERROR_NONE

[scottmac]

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

 ID: 53963
 Updated by: scott...@php.net
 Reported by:h...@php.net
 Summary:Failed to decode, yet json_last_error() is
 JSON_ERROR_NONE
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:JSON related
 PHP Version:5.3.5
 Assigned To:scottmac
 Block user comment: N
 Private report: N



Previous Comments:

[2011-02-09 09:05:02] scott...@php.net

Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revision&revision=308155
Log: Fix Bug #53963, error code isn't always set in certain error cases.


[2011-02-09 08:00:50] ahar...@php.net

Here's a much simpler test case based on the munged JSON from

atsearch.autotrader.co.uk:







Obviously json_last_error() should return something other than 0,

presumably JSON_ERROR_SYNTAX (4), since it's not syntactically

valid JSON.


[2011-02-08 20:23:48] h...@php.net

Description:

I'm trying the json_decode() function on real world strings, not just
from strings 

produced using json_encode().



I have included the test case from bug #52262 as well to show that this
issue is 

different.



Thanks.

Test script:
---


http://dealerservices.autotrader.co.uk/14184/cars.htm */

$urls[]='http://atsearch.autotrader.co.uk/js/uvl/InlineServlet.js?did=14184&configfile=http://dealerservices.autotrader.co.uk/dealers/14184/14184_config.xml&csslocation=http://dealerservices.autotrader.co.uk/dealers/14184/14184&dropdowntype=uvl&partner=TMG&postcode=me86ad&miles=1500&sort=5&action=searchresults';

/* from http://api.jquery.com/jQuery.getJSON/ */

$urls[]='http://api.flickr.com/services/feeds/photos_public.gne?jsoncallback=jQuery15094986786483787_1297190250272&tags=cat&tagmode=any&format=json&_=1297190250280';

/* from
http://code.google.com/apis/base/samples/javascript/tutorial.html */

$urls[]='http://www.google.com/base/feeds/attributes/-/vehicles?max-values=30&bq=[target%20country:GB]&alt=json-in-script&callback=showMake';

/* from http://code.google.com/apis/gdata/docs/json.html */

$urls[]='http://www.google.com/calendar/feeds/developer-calen...@google.com/public/full?alt=json';

/* from http://code.google.com/apis/gdata/docs/json.html */

$urls[]='http://www.google.com/calendar/feeds/developer-calen...@google.com/public/full?alt=json-in-script&callback=myFunction';

/* from http://bugs.php.net/bug.php?id=52262 */

$urls[]='http://api.steampowered.com/ISteamUserStats/GetGlobalAchievementPercentagesForApp/v0001/?gameid=440';



/* from http://php.net/manual/en/function.json-last-error.php */

$json_errors=array( -1 => 'An unknown error occured',


JSON_ERROR_NONE => 'No error has occurred',


JSON_ERROR_DEPTH => 'The maximum stack depth has been
exceeded',


JSON_ERROR_CTRL_CHAR => 'Control character error, possibly
incorrectly encoded',


JSON_ERROR_STATE_MISMATCH => 'Invalid or malformed JSON',


JSON_ERROR_SYNTAX => 'Syntax error',


JSON_ERROR_UTF8 => 'Malformed UTF-8 characters, possibly
incorrectly encoded');



/* main loop */

foreach($urls as $url) {

echo PHP_EOL;



//call the json

$json=file_get_contents($url);

echo 'Decoding... ' . $url . PHP_EOL;



//convert from jsonp to json

$json=preg_replace('/.+?({.+}).+/','$1',$json);



//get a result

$result=json_decode($json);

if ($result) {

echo 'Decoded.';

} else {

  echo 'Failed to decode.';

}

echo PHP_EOL;



$err=json_last_error();

if ($err != JSON_ERROR_NONE) {

echo 'Error: ';

echo 
isset($json_errors[$err])?$json_errors[$err]:$json_errors[-1];

} else {

echo 'No error.';

}

echo PHP_EOL;

}



//eof

Expected result:

The first result should either:



* Decode successfully and have no error (preferable)

Or

* Fail to decode and have an error which explains why

Actual result:
--


Decoding... http://atsearch.autotrader.co.uk/js/uvl/InlineServlet.js?

did=14184&configfile=http://dealerservices.autotrader.co.uk/dealers/14184/14184_

[PHP-BUG] Req #53968 [NEW]: Non-breaking spaces are considered as a valid identifier character

[ivan dot enderlin at hoa-project dot net]

From: 
Operating system: 
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:Non-breaking spaces are considered as a valid identifier 
character

Description:

Hey :-),



Just a noticeable think that PHP allows is the use of non-breaking space
(0x00A0) as a valid identifier character. Thus, we can have very strange
code (but I love it)! See bellow.



It is not a bug, just a fact that makes PHP awesome.

Test script:
---
f g h();



// Go deeper.

function   ( ) {



var_dump('succeed (2)');

}



 ();



// Go crazy!

class   {



public function    ( ) {



var_dump('succeed (3)');

}

}



$  = new  ();

$ ->  ();



echo 'PHP is awesome :-).' . "\n";

Expected result:

string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).

Actual result:
--
string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).

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

Req #51915 [Opn->Bgs]: numeric string key escaped in type change

[scottmac]

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

 ID: 51915
 Updated by: scott...@php.net
 Reported by:laruence at yahoo dot com dot cn
 Summary:numeric string key escaped in type change
-Status: Open
+Status: Bogus
 Type:   Feature/Change Request
 Package:JSON related
 Operating System:   linux
 PHP Version:5.2.13
 Block user comment: N
 Private report: N

 New Comment:

When an array is of mixed type or doesn't contain sequential keys it has
to be 

treated as a hash and not as an integer



json_encode() turns the integer keys into strings which it has to do to
be valid 

json.



On json_decode() it see's string keys instead of numeric since this is a
hash 

not an array.



There is nothing unexpected happening here.


Previous Comments:

[2010-06-07 10:03:41] xiezhenye at gmail dot com

there is an easier way to build such an array.



$obj = new stdClass;

$obj->{'123'} = 1;

$arr = (array) $obj;

var_dump($obj);


[2010-05-27 04:15:01] laruence at yahoo dot com dot cn

change bug to Feature , nhancement


[2010-05-26 08:30:18] laruence at yahoo dot com dot cn

Description:

php treat numeric string key as interge,



bug sometimes there is some exception.



for example:

  while change a std object to array, numeric string key doesn't cast to
number 

Test script:
---
 'laruence',

"03"=> 'baidu',

);



$value = json_encode($data);

$obj   = json_decode($value);

$arr   = (array)$obj;

var_dump($arr);

?>

Expected result:

array(2) {

  [123]=>

  string(8) "laruence"

  ["03"]=>

  string(5) "baidu"

}



Actual result:
--
array(2) {

  ["123"]=>

  string(8) "laruence"

  ["03"]=>

  string(5) "baidu"

}








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

Req #53968 [Opn->Bgs]: Non-breaking spaces are considered as a valid identifier character

[scottmac]

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

 ID: 53968
 Updated by: scott...@php.net
 Reported by:ivan dot enderlin at hoa-project dot net
 Summary:Non-breaking spaces are considered as a valid
 identifier character
-Status: Open
+Status: Bogus
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

if its not a bug why report it here?


Previous Comments:

[2011-02-09 09:15:59] ivan dot enderlin at hoa-project dot net

Description:

Hey :-),



Just a noticeable think that PHP allows is the use of non-breaking space
(0x00A0) as a valid identifier character. Thus, we can have very strange
code (but I love it)! See bellow.



It is not a bug, just a fact that makes PHP awesome.

Test script:
---
f g h();



// Go deeper.

function   ( ) {



var_dump('succeed (2)');

}



 ();



// Go crazy!

class   {



public function    ( ) {



var_dump('succeed (3)');

}

}



$  = new  ();

$ ->  ();



echo 'PHP is awesome :-).' . "\n";

Expected result:

string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).

Actual result:
--
string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).






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

Req #53968 [Com]: Non-breaking spaces are considered as a valid identifier character

[ivan dot enderlin at hoa-project dot net]

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

 ID: 53968
 Comment by: ivan dot enderlin at hoa-project dot net
 Reported by:ivan dot enderlin at hoa-project dot net
 Summary:Non-breaking spaces are considered as a valid
 identifier character
 Status: Bogus
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

To alert developers and prove that it is not a bug :-).


Previous Comments:

[2011-02-09 09:26:04] scott...@php.net

if its not a bug why report it here?


[2011-02-09 09:15:59] ivan dot enderlin at hoa-project dot net

Description:

Hey :-),



Just a noticeable think that PHP allows is the use of non-breaking space
(0x00A0) as a valid identifier character. Thus, we can have very strange
code (but I love it)! See bellow.



It is not a bug, just a fact that makes PHP awesome.

Test script:
---
f g h();



// Go deeper.

function   ( ) {



var_dump('succeed (2)');

}



 ();



// Go crazy!

class   {



public function    ( ) {



var_dump('succeed (3)');

}

}



$  = new  ();

$ ->  ();



echo 'PHP is awesome :-).' . "\n";

Expected result:

string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).

Actual result:
--
string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).






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

Req #53968 [Bgs]: Non-breaking spaces are considered as a valid identifier character

[scottmac]

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

 ID: 53968
 Updated by: scott...@php.net
 Reported by:ivan dot enderlin at hoa-project dot net
 Summary:Non-breaking spaces are considered as a valid
 identifier character
 Status: Bogus
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

It's in the manual.



A letter in PHP is considered to be a-z,A-Z and 0x7f-0xff


Previous Comments:

[2011-02-09 09:27:51] ivan dot enderlin at hoa-project dot net

To alert developers and prove that it is not a bug :-).


[2011-02-09 09:26:04] scott...@php.net

if its not a bug why report it here?


[2011-02-09 09:15:59] ivan dot enderlin at hoa-project dot net

Description:

Hey :-),



Just a noticeable think that PHP allows is the use of non-breaking space
(0x00A0) as a valid identifier character. Thus, we can have very strange
code (but I love it)! See bellow.



It is not a bug, just a fact that makes PHP awesome.

Test script:
---
f g h();



// Go deeper.

function   ( ) {



var_dump('succeed (2)');

}



 ();



// Go crazy!

class   {



public function    ( ) {



var_dump('succeed (3)');

}

}



$  = new  ();

$ ->  ();



echo 'PHP is awesome :-).' . "\n";

Expected result:

string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).

Actual result:
--
string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).






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

Req #53968 [Com]: Non-breaking spaces are considered as a valid identifier character

[ivan dot enderlin at hoa-project dot net]

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

 ID: 53968
 Comment by: ivan dot enderlin at hoa-project dot net
 Reported by:ivan dot enderlin at hoa-project dot net
 Summary:Non-breaking spaces are considered as a valid
 identifier character
 Status: Bogus
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Yup I know it. I precise that it is not a bug, but if someone searches,
thinking that it is a bug, he will probably find this “bug” and got
its answer.


Previous Comments:

[2011-02-09 09:45:46] scott...@php.net

It's in the manual.



A letter in PHP is considered to be a-z,A-Z and 0x7f-0xff


[2011-02-09 09:27:51] ivan dot enderlin at hoa-project dot net

To alert developers and prove that it is not a bug :-).


[2011-02-09 09:26:04] scott...@php.net

if its not a bug why report it here?


[2011-02-09 09:15:59] ivan dot enderlin at hoa-project dot net

Description:

Hey :-),



Just a noticeable think that PHP allows is the use of non-breaking space
(0x00A0) as a valid identifier character. Thus, we can have very strange
code (but I love it)! See bellow.



It is not a bug, just a fact that makes PHP awesome.

Test script:
---
f g h();



// Go deeper.

function   ( ) {



var_dump('succeed (2)');

}



 ();



// Go crazy!

class   {



public function    ( ) {



var_dump('succeed (3)');

}

}



$  = new  ();

$ ->  ();



echo 'PHP is awesome :-).' . "\n";

Expected result:

string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).

Actual result:
--
string(11) "succeed (1)"

string(11) "succeed (2)"

string(11) "succeed (3)"

PHP is awesome :-).






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

[PHP-BUG] Bug #53969 [NEW]: Can't remove .res file after using ResourceBundle

[jinmoku at hotmail dot com]

From: 
Operating system: Windows 7
PHP version:  5.3.5
Package:  I18N and L10N related
Bug Type: Bug
Bug description:Can't remove .res file after using ResourceBundle

Description:

I Can't remove .res file after using ResourceBundle, the only way to remove
it, it's to stop apache.



after run this following code, try to delete the .res file

Test script:
---
$res =
'http://svn.php.net/repository/php/php-src/tags/php_5_3_5/ext/intl/tests/_files/resourcebundle/root.res';

$file = basename($res);



if(!file_exists($file))

{

copy($res, basename($res));

}



$r = new ResourceBundle( 'en_US', realpath(__DIR__));

echo $r->get('teststring');



unset($r);



unlink($file);

Expected result:

Hello World!

Actual result:
--
Warning: unlink(root.res): Permission denied in C:\www\test\index.php on
line 16

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

Bug #52911 [Com]: fwrite doesn't write long strings to a php stream

[tyra3l at gmail dot com]

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

 ID: 52911
 Comment by: tyra3l at gmail dot com
 Reported by:mz dot evgeny at gmail dot com
 Summary:fwrite doesn't write long strings to a php stream
 Status: Verified
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

any update on this?



Tyrael


Previous Comments:

[2010-10-17 10:49:09] bouke at webatoom dot nl

I ran into the same problem, but sleep(1) didn't work. I had to use
sleep(2) 

on my machine (Win7 x64 on C2Q9450).


[2010-09-24 04:45:37] cataphr...@php.net

Strangely, it works if you sleep(1) after proc_open.


[2010-09-23 13:36:35] mz dot evgeny at gmail dot com

It will be more correct to say that it does write the whole string, but
php.exe doesn't get the complete string for some reason.


[2010-09-23 13:18:34] mz dot evgeny at gmail dot com

Description:

fwrite doesn't write long strings to a stream.



When i try to open a php process and write a long-script to it, i get a
parse error.



Test script:
---
 $descriptorSpec = array(

  0 => array('pipe', 'r'),

  1 => array('pipe', 'w'),

  2 => array('pipe', 'w')

 );

 $process = proc_open("php.exe", $descriptorSpec, $pipes); 

 var_dump(fwrite($pipes[0], ""));

 fclose($pipes[0]);



 $stdout = stream_get_contents($pipes[1]);

 fclose($pipes[1]);

proc_close($process);

 print_r($stdout);



Expected result:

int 8513

No error.

Actual result:
--
int 8513

Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE in - on
line 1 






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

Bug #52911 [Ver]: fwrite doesn't write long strings to a php stream

[pajoye]

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

 ID: 52911
 Updated by: paj...@php.net
 Reported by:mz dot evgeny at gmail dot com
 Summary:fwrite doesn't write long strings to a php stream
 Status: Verified
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

If there is no further comment, no, no news.



Also there is a limit in the size of the command line arguments
(platform-version 

dependent), so using very long cmd line is a bad idea, pipes or file
based 

argument is a way better way to do such things.


Previous Comments:

[2011-02-09 10:26:59] tyra3l at gmail dot com

any update on this?



Tyrael


[2010-10-17 10:49:09] bouke at webatoom dot nl

I ran into the same problem, but sleep(1) didn't work. I had to use
sleep(2) 

on my machine (Win7 x64 on C2Q9450).


[2010-09-24 04:45:37] cataphr...@php.net

Strangely, it works if you sleep(1) after proc_open.


[2010-09-23 13:36:35] mz dot evgeny at gmail dot com

It will be more correct to say that it does write the whole string, but
php.exe doesn't get the complete string for some reason.


[2010-09-23 13:18:34] mz dot evgeny at gmail dot com

Description:

fwrite doesn't write long strings to a stream.



When i try to open a php process and write a long-script to it, i get a
parse error.



Test script:
---
 $descriptorSpec = array(

  0 => array('pipe', 'r'),

  1 => array('pipe', 'w'),

  2 => array('pipe', 'w')

 );

 $process = proc_open("php.exe", $descriptorSpec, $pipes); 

 var_dump(fwrite($pipes[0], ""));

 fclose($pipes[0]);



 $stdout = stream_get_contents($pipes[1]);

 fclose($pipes[1]);

proc_close($process);

 print_r($stdout);



Expected result:

int 8513

No error.

Actual result:
--
int 8513

Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE in - on
line 1 






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

Bug #52406 [Com]: spl_autoload support phar with namespace

[jinmoku at hotmail dot com]

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

 ID: 52406
 Comment by: jinmoku at hotmail dot com
 Reported by:jinmoku at hotmail dot com
 Summary:spl_autoload support phar with namespace
 Status: To be documented
 Type:   Bug
 Package:SPL related
 Operating System:   XP, OSX
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Only way to work :



$phar->addFromString(strtolower('index.php'), $index);

$phar->addFromString(strtolower('Framework/Test.php'), $contents);



or maybe do it in internal


Previous Comments:

[2010-07-23 11:11:51] jinmoku at hotmail dot com

Ok, I retry on XP and it's work, even if it isn't simple, a filename in
project is not always in lowercase...



Unfortunately it's doesn't work on osx, we see :
set_include_path('phar://' . __FILE__ . PATH_SEPARATOR .
get_include_path());



but after the require_once the phar path's gone, i'll check on other
system and I come back



;)


[2010-07-23 01:59:42] fel...@php.net

What I am saying is:



- Using require_once you might use (lowercase not required):

$phar->addFromString('Framework/Test.php', $contents);

require_once 'Framework/Test.php'; // the search is non-lowercased



- Using spl_autoload() you must use (lowercase required):

$phar->addFromString('framework/test.php', $contents);

$test = new Framework\Test(); // spl_autoload() searchs for the
lowercased namespace/classname.php


[2010-07-23 01:44:48] jinmoku at hotmail dot com

oups, caracteres don't passed, you can find the phar here :
http://backfront.org/MyPhar.phar



;)


[2010-07-23 01:36:47] jinmoku at hotmail dot com

Do u have a sample code who doesn't work with the lowercase, I want to
test in my osx ?



about :

> I can't reproduce the weird chars...



I've this in my phar 



Extract_Phar::go();

__HALT_COMPILER(); ?>e


[2010-07-23 01:22:59] fel...@php.net

I can't reproduce the weird chars...



About this is work...:

require_once('MyPhar.phar');

set_include_path('phar://' . realpath('MyPhar.phar') . PATH_SEPARATOR .
get_include_path());

require_once 'Framework/Test.php';



It's because that in this case the require_once doesn't look into the
file system at all, but into the phar structure, so it doesnt search for
the lowercased one, as in the other sample code.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=52406


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

Bug #53844 [Fbk]: PHP built from source on Solaris gets SIGSEGV with libiconv

[johannes]

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

 ID: 53844
 Updated by: johan...@php.net
 Reported by:r at rcrowley dot org
 Summary:PHP built from source on Solaris gets SIGSEGV with
 libiconv
 Status: Feedback
 Type:   Bug
 Package:ICONV related
 Operating System:   Solaris
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

I meant to write --disable-all, sorry for the mistake. Could you try



   ./configure --disable-all --with-iconv && make && ./sapi/cli/php -r
'echo iconv("UTF-8", "UTF-8", "Hello, world.\n");'


Previous Comments:

[2011-02-09 01:15:59] phil at quizlet dot com

No luck...



With the original configuration, I tried:



# LD_LIBRARY_PATH=/opt/local/lib ; export LD_LIBRARY_PATH ; php -r 'echo


iconv("UTF-8", "UTF-8", "Hello, world.\n");'



as well as:



# LD_LIBRARY_PATH=/opt/local/lib php -r 'echo iconv("UTF-8", "UTF-8",
"Hello, 

world.\n");'



as well as reconfiguring with:



# ./configure --disable-iconv --with-iconv



and also tried:



# ./configure LDFLAGS=/opt/local/lib --with-iconv



and:



# ./configure LDFLAGS=/opt/local/lib --disable-iconv --with-iconv



Note: I did get a "Notice: Following unknown configure options were
used: --

disable-iconv" when trying to follow johannes advice, and
--disable-iconv isn't 

listed in ./configure --help.



In ALL of the above cases when testing PHP's iconv() I got a segfault
and 

checked the backtrace with gdb after each and they were all identical:



(gdb) bt

#0  0xec835356 in ?? ()

#1  0xfe8d68ab in iconv () from /lib/libc.so.1

#2  0x0815a2b1 in php_iconv_string (in_p=0x8653484 "Hello, world.\n",
in_len=14, 

out=0x8047580, out_len=0x8047584, out_charset=0x8653458 "UTF-8", 

in_charset=0x8654900 "UTF-8")

at /tmp/tmp..Aa4sh/php-5.3.5/ext/iconv/iconv.c:501

#3  0x0815d274 in php_if_iconv (ht=3, return_value=0x865349c, 

return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at
/tmp/tmp..Aa4sh/php-

5.3.5/ext/iconv/iconv.c:2327

#4  0x083147de in zend_do_fcall_common_helper_SPEC
(execute_data=0x8793f70) at 

zend_vm_execute.h:316

#5  0x0831385d in execute (op_array=0x8653384) at zend_vm_execute.h:107

#6  0x082e6e29 in zend_eval_stringl (str=0x8047ccb "echo
iconv(\"UTF-8\", \"UTF-

8\", \"Hello, world.\\n\");", str_len=48, retval_ptr=0x0,
string_name=0x85c30ae 

"Command line code")

at /tmp/tmp..Aa4sh/php-5.3.5/Zend/zend_execute_API.c:1193

#7  0x082e6fe2 in zend_eval_stringl_ex (str=0x8047ccb "echo
iconv(\"UTF-8\", 

\"UTF-8\", \"Hello, world.\\n\");", str_len=48, retval_ptr=0x0, 

string_name=0x85c30ae "Command line code", 

handle_exceptions=1) at /tmp/tmp..Aa4sh/php-

5.3.5/Zend/zend_execute_API.c:1235

#8  0x082e705a in zend_eval_string_ex (str=0x8047540 "\016",
retval_ptr=0x0, 

string_name=0x85c30ae "Command line code", handle_exceptions=1) at 

/tmp/tmp..Aa4sh/php-5.3.5/Zend/zend_execute_API.c:1246

#9  0x08376724 in main (argc=3, argv=0x8047bdc) at /tmp/tmp..Aa4sh/php-

5.3.5/sapi/cli/php_cli.c:1282



Any other ideas?


[2011-02-08 03:23:32] srina...@php.net

what happens when you do some thing like

LD_LIBRARY_PATH=/opt/local/lib ; export LD_LIBRARY_PATH ; php -r 'echo
iconv("UTF-8", "UTF-8", "Hello, world.\n");'


[2011-02-07 20:55:49] phil at quizlet dot com

(I'm working with Richard on this...)



[root@gnp2b7ak ~]# showrev

Hostname: ...

Hostid: c54426

Release: 5.11

Kernel architecture: i86pc

Application architecture: i386

Hardware provider: 

Domain: 

Kernel version: SunOS 5.11 snv_121



Joyent (the hosting provider) has kindly offered a free Joyent Solaris
instance 

for you to test against, if you'd like. Just email me and I'll get it
set up.


[2011-02-07 19:46:23] johan...@php.net

Which version of solaris are you using? My Solaris 11 express works
fine. Could you also try doing a



./configure --disable-iconv --with-iconv



build? Yor stacktrace shows 

   #1  0xfe8d68ab in iconv () from /lib/libc.so.1

so the libc's iconv is being used. My assumption is that another library
is using iconv from /opt/local and so the linker pulls the libs in the
wrong order so one version is used for compiling PHP the other for
running ...


[2011-02-07 17:16:45] r at rcrowley dot org

# iconv --version

iconv (GNU libiconv 1.11)

Copyright (C) 2000-2007 Free Software Foundation, Inc.

License GPLv2+: GNU GPL version 2 or later


This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Written by

[PHP-BUG] Bug #53970 [NEW]: PDOStatement::execute returns TRUE even when sql statement is not executed

[lopez at freshsite dot de]

From: 
Operating system: Windows
PHP version:  Irrelevant
Package:  PDO related
Bug Type: Bug
Bug description:PDOStatement::execute returns TRUE even when sql statement is 
not executed

Description:

I recognized, that the return value stay TRUE, even if the sql statement
could not be executed correctly.

Test script:
---
Example:

$sth = $this->db->prepare("REPLACE INTO test

SET bar = 
:foo);

$error = $sth->execute(array('foo' => 'bar'));



/*

$error will be TRUE, because sql is correct and sent.



However, if the mysql user has not the rights (INSERT,DELETE) to do this,
the statement will be not executed at all without error message.



So, don't rely on the returning value until this is fixed!

Expected result:

$error should be FALSE

Actual result:
--
$error is TRUE

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

Bug #49139 [Opn->Fbk]: proc_open requires double quotes

[pajoye]

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

 ID: 49139
 Updated by: paj...@php.net
 Reported by:david dot gausmann at measx dot com
 Summary:proc_open requires double quotes
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Program Execution
 Operating System:   win32 only - Windows XP SP3
 PHP Version:5.3.0
-Assigned To:
+Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

@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(stream_get_contents($pipes[2]));



echo PHP_EOL;

echo "exec: " . PHP_EOL;

echo exec($cmd, $ret);

echo PHP_EOL;

print_r($ret);

echo PHP_EOL;



gives me:



string(0) ""

string(441) "Usage: wcutil [-s] [-d] [-x] [filename(*)]

-s(imple)  Do not display CSV headers or average.

-x(ml) Xml output.

-d(rophighlow) Drop highest and lowest path runs.



Column details:

file   - output filename

tps- transactions per second

kcpt   - kilocycles per transaction (aka 'path')

bpt- bytes per transaction

cpu- percent CPU utilization

err- count of any errors



"

string(0) ""



exec:



Array

(

[0] => Usage: wcutil [-s] [-d] [-x] [filename(*)]

[1] => -s(imple)  Do not display CSV headers or average.

[2] => -x(ml) Xml output.

[3] => -d(rophighlow) Drop highest and lowest path runs.

[4] =>

[5] => Column details:

[6] => file   - output filename

[7] => tps- transactions per second

[8] => kcpt   - kilocycles per transaction (aka 'path')

[9] => bpt- bytes per transaction

[10] => cpu- percent CPU utilization

[11] => err- count of any errors

[12] =>

)



which is correct.



Using 5.3.5 and 5.3-svn or trunk, on Windows 7/2003/2008.



Please try again and let me know if it still fails, using this exact
sample (can 

be other command), or repost an example to reproduce it. I will also
need to 

know which windows version you use.


Previous Comments:

[2011-01-26 16:27:21] xc at ez dot no

Can someone speed up the fix? We have issue in our project based on this
bug.



I assume second call in the example should work..



Related issue: https://issues.apache.org/jira/browse/ZETACOMP-48



Thanks.


[2010-04-23 08:46:52] David dot Gausmann at measx dot com

This is the same problem as mine:



$Command = '""c:\program files\doxygen\bin\doxygen.exe"
"C:\fred\doxyfile""';



$DescriptorSpecification = array

(

   0 => array('pipe', 'r'),

   1 => array('pipe', 'w'),

   2 => array('pipe', 'w')

);



$Resource = proc_open($Command, $DescriptorSpecification, $Pipes, null,
$_ENV);



Works fine (because it has the nasty double quotes around everything).


[2010-04-23 02:22:47] xandrani at googlemail dot com

The double backward slashes didn't show correctly... but they are in my
code.


[2010-04-23 02:20:33] xandrani at googlemail dot com

Something similar fails for me... but even worse!



$Command = '"c:\program files\doxygen\bin\doxygen.exe"
"C:\fred\doxyfile"'



$DescriptorSpecification = array

(

   0 => array('pipe', 'r'),

   1 => array('pipe', 'w'),

   2 => array('pipe', 'w')

);



$Resource = proc_open($Command, $DescriptorSpecification, $Pipes, null,
$_ENV);



I get the error:

'c:\program' is not recognized as an internal or external command,
operable program or batch file.



This works on exec() so not sure what's going on.


[2009-08-03 13:09:56] david dot gausmann at measx dot com

Description:

The command, which shall be executed via proc_open, must be put in
double quotes.

This bug was on functions like system, exec, ...

It seems not to be fixed on proc_open.

Reproduce code:
---
--- script1.php ---



---script2.php---



Expected result:

1.

Lorem ipsum

2.

Lorem ipsum

3.



The third call of proc_open should fail, the second one should work.

Actual result:
--
1.

Lorem ipsum

2.

3.

Lorem ipsum



The second call of proc_open should fails, but the third one works.






-- 
Edit this bug re

Bug #52752 [Com]: Program terminated with signal 7, Bus error.

[paulgao at yeah dot net]

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

 ID: 52752
 Comment by: paulgao at yeah dot net
 Reported by:paulgao at yeah dot net
 Summary:Program terminated with signal 7, Bus error.
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Centos 5 32bit
 PHP Version:5.3SVN-2010-08-31 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

BBB' . "\r\n", LOCK_EX);



require_once __DIR__ . '/test.tpl';



?>



please use “ab -n 200 -n 20 http://localhost/test.php“ to test it.


Previous Comments:

[2010-11-24 00:20:11] fel...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




[2010-09-09 07:39:16] paulgao at yeah dot net

and, centos 64bit server, same result.


[2010-09-04 18:24:58] paulgao at yeah dot net

Anybody There?


[2010-09-02 08:15:49] paulgao at yeah dot net

please use “ab -n 200 -n 20 http://xxx/xxx.php“ test.


[2010-09-01 15:19:11] paulgao at yeah dot net

script run in Centos 5 32bit server, php-fpm mode.



configure command:

./configure --prefix=/usr/local/php --without-pear --with-mysqli=mysqlnd
--disable-phar --with-iconv --with-zlib --enable-exif --enable-sockets
--enable-mbstring=all --enable-inline-optimization --enable-debug
--enable-static --disable-ipv6 --disable-pdo --without-sqlite
--enable-fpm --with-libevent=shared




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=52752


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

Bug #52752 [Com]: Program terminated with signal 7, Bus error.

[paulgao at yeah dot net]

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

 ID: 52752
 Comment by: paulgao at yeah dot net
 Reported by:paulgao at yeah dot net
 Summary:Program terminated with signal 7, Bus error.
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Centos 5 32bit
 PHP Version:5.3SVN-2010-08-31 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

core dump:



(gdb) bt

#0  0x082a1ac8 in lex_scan (zendlval=0xbf85525c) at
/root/php-5.3.5/Zend/zend_language_scanner.c:2063

#1  0x082b2df8 in zendlex (zendlval=0xbf855258) at
/root/php-5.3.5/Zend/zend_compile.c:4949

#2  0x0829c0f9 in zendparse () at
/root/php-5.3.5/Zend/zend_language_parser.c:3280

#3  0x082a0f3c in compile_file (file_handle=0xbf855330, type=8) at
/root/php-5.3.5/Zend/zend_language_scanner.c:359

#4  0x082fa1ca in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER
(execute_data=0x9fbd1b8) at /root/php-5.3.5/Zend/zend_vm_execute.h:5200

#5  0x082ed7e8 in execute (op_array=0x9f88d68) at
/root/php-5.3.5/Zend/zend_vm_execute.h:107

#6  0x082cb847 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.5/Zend/zend.c:1194

#7  0x0827ae7e in php_execute_script (primary_file=0xbf859858) at
/root/php-5.3.5/main/main.c:2265

#8  0x08352122 in main (argc=131072, argv=0x640004) at
/root/php-5.3.5/sapi/fpm/fpm/fpm_main.c:1882


Previous Comments:

[2011-02-09 12:38:42] paulgao at yeah dot net

BBB' . "\r\n", LOCK_EX);



require_once __DIR__ . '/test.tpl';



?>



please use “ab -n 200 -n 20 http://localhost/test.php“ to test it.


[2010-11-24 00:20:11] fel...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




[2010-09-09 07:39:16] paulgao at yeah dot net

and, centos 64bit server, same result.


[2010-09-04 18:24:58] paulgao at yeah dot net

Anybody There?


[2010-09-02 08:15:49] paulgao at yeah dot net

please use “ab -n 200 -n 20 http://xxx/xxx.php“ test.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=52752


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

Bug #53961 [Bgs->Opn]: soap over https with custom port does work

[cataphract]

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

 ID: 53961
 Updated by: cataphr...@php.net
 Reported by:bender at digitalbase dot de
 Summary:soap over https with custom port does work
-Status: Bogus
+Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   WinXP 32bit
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

Re-open as the bug reported missed a "not" in his comment.



Citing the e-mail he sent:



«

> which version does not work? 

PHP 5.3.0 works

PHP 5.3.3 does not work

PHP 5.3.4 does not work

PHP 5.3.5 does not work

> Is it available through windows.php.net?  

Yes,
http://windows.php.net/downloads/releases/php-5.3.5-Win32-VC9-x86.zip

»


Previous Comments:

[2011-02-09 00:44:34] cataphr...@php.net

Well, if the current version works, I'm closing this bug.


[2011-02-08 19:44:10] bender at digitalbase dot de

the current version does work PHP 5.3.5


[2011-02-08 18:30:09] cataphr...@php.net

I have no problems with 0.9.8o-1ubuntu4.3



I can test on Windows, but to be clear: which version does not work? Is
it available through windows.php.net? Which package is it?


[2011-02-08 17:28:55] bender at digitalbase dot de

Description:

SoapClient does work with https over custom port.



If one version is the OpenSSl.dll (OpenSSL 0.9.8l) from an earlier PHP
take it to work. With the current, it does not work.











Test script:
---
// does work

$client = new SoapClient("https://localhost:21081/test_13?wsdl";);







// works

$client = new SoapClient("https://localhost/test_13?wsdl";);





Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'https://localhost:21081/test_13?wsdl' : Start
tag expected, '<' not found in C:\htdocs\wwwroot\test.php:4 Stack trace:
#0 C:\htdocs\wwwroot\test.php(4):
SoapClient->SoapClient('https://local...') #1 {main} thrown in
C:\htdocs\wwwroot\test.php on line 4






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

Bug #53961 [Opn]: soap over https with custom port does work

[pajoye]

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

 ID: 53961
 Updated by: paj...@php.net
 Reported by:bender at digitalbase dot de
 Summary:soap over https with custom port does work
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   WinXP 32bit
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

and snaps per revision are available at http://rmtools.php.net/snaps/


Previous Comments:

[2011-02-09 12:57:33] cataphr...@php.net

Re-open as the bug reported missed a "not" in his comment.



Citing the e-mail he sent:



«

> which version does not work? 

PHP 5.3.0 works

PHP 5.3.3 does not work

PHP 5.3.4 does not work

PHP 5.3.5 does not work

> Is it available through windows.php.net?  

Yes,
http://windows.php.net/downloads/releases/php-5.3.5-Win32-VC9-x86.zip

»


[2011-02-09 00:44:34] cataphr...@php.net

Well, if the current version works, I'm closing this bug.


[2011-02-08 19:44:10] bender at digitalbase dot de

the current version does work PHP 5.3.5


[2011-02-08 18:30:09] cataphr...@php.net

I have no problems with 0.9.8o-1ubuntu4.3



I can test on Windows, but to be clear: which version does not work? Is
it available through windows.php.net? Which package is it?


[2011-02-08 17:28:55] bender at digitalbase dot de

Description:

SoapClient does work with https over custom port.



If one version is the OpenSSl.dll (OpenSSL 0.9.8l) from an earlier PHP
take it to work. With the current, it does not work.











Test script:
---
// does work

$client = new SoapClient("https://localhost:21081/test_13?wsdl";);







// works

$client = new SoapClient("https://localhost/test_13?wsdl";);





Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'https://localhost:21081/test_13?wsdl' : Start
tag expected, '<' not found in C:\htdocs\wwwroot\test.php:4 Stack trace:
#0 C:\htdocs\wwwroot\test.php(4):
SoapClient->SoapClient('https://local...') #1 {main} thrown in
C:\htdocs\wwwroot\test.php on line 4






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

[PHP-BUG] Bug #53971 [NEW]: isset() and empty() produce apparently spurious runtime error

[david at frankieandshadow dot com]

From: 
Operating system: Linux, Redhat Enterprise
PHP version:  5.3.5
Package:  Arrays related
Bug Type: Bug
Bug description:isset() and empty() produce apparently spurious runtime error

Description:

First, apologies, this is 5.3.3. I have no means of upgrading to check
whether 

this is a fixed issue. I can't see anything similar in the bug database.



An expression of the form 

  isset($obj->m['a']['b'])

produces a runtime error when m is not actually an array but a zero length


string:

  Uninitialized string offset: 0

The same is the case if I use empty instead of isset.

The same code worked in 5.2. Changing it to 

  isset($obj->m['a']) && isset($obj->m['a']['b'])

works.



isset is not supposed to produce any runtime error, surely, in this kind of
use.



The object member values arise from a database lookup, and normally the
field (m 

above) will be a serialized array in the database, but the first time the 

database column will be empty, leading to an empty string assignment to m.
In 

addition once populated the object is stored in $_SESSION (actually in 

$_SESSION['p']['q']) and then $obj is obtained by assignment from the
session, 

like this

  $session =& $_SESSION['p']; // where $_SESSION['p'] is set in a previous
page

  // populate new $obj1 from database

  $session['q'] = $obj1;

  ...

  $obj =& $session['q'];

and the offending code is then executed elsewhere some time later.



However, abstracting the code from this much bigger program does not
demonstrate 

the problem, which suggests to me something is corrupted somewhere. This is
what 

I tried on its own, which is as close as I can reasonably get to the
situation 

here, but it works. (The =& are leftovers from what was originally a PHP4
app; I 

know all objects are assigned by reference in PHP5).



class c { var $m; }



session_start();

if (! isset($_SESSION['p'])) {

  $_SESSION['p'] = array();

  echo "set session array";

  exit;

}

$session =& $_SESSION['p'];

$obj1 = new c();

$obj1->m = '';

$session['q'] = $obj1;

$obj =& $session['q'];

function check() {

  global $obj;

  echo (isset($obj->m['a']['b']) ? 'Yes' : 'No');

}

check();

Expected result:

isset to return FALSE

Actual result:
--
runtime error

Uninitialized string offset: 0

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

Bug #53961 [Opn]: soap over https with custom port does work

[cataphract]

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

 ID: 53961
 Updated by: cataphr...@php.net
 Reported by:bender at digitalbase dot de
 Summary:soap over https with custom port does work
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   WinXP 32bit
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

I can't reproduce:



D:\Users\Cataphract\Desktop\php-5.3.5-Win32-VC9-x86>php -d
extension_dir=ext -d

extension=php_soap.dll -d extension=php_openssl.dll -r "$client = new
SoapClient

('https://192.168.4.5:21083/test_13.xml'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(6) of type (Unknown)

}


Previous Comments:

[2011-02-09 13:01:08] paj...@php.net

and snaps per revision are available at http://rmtools.php.net/snaps/


[2011-02-09 12:57:33] cataphr...@php.net

Re-open as the bug reported missed a "not" in his comment.



Citing the e-mail he sent:



«

> which version does not work? 

PHP 5.3.0 works

PHP 5.3.3 does not work

PHP 5.3.4 does not work

PHP 5.3.5 does not work

> Is it available through windows.php.net?  

Yes,
http://windows.php.net/downloads/releases/php-5.3.5-Win32-VC9-x86.zip

»


[2011-02-09 00:44:34] cataphr...@php.net

Well, if the current version works, I'm closing this bug.


[2011-02-08 19:44:10] bender at digitalbase dot de

the current version does work PHP 5.3.5


[2011-02-08 18:30:09] cataphr...@php.net

I have no problems with 0.9.8o-1ubuntu4.3



I can test on Windows, but to be clear: which version does not work? Is
it available through windows.php.net? Which package is it?




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=53961


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

Bug #53961 [Opn]: soap over https with custom port does work

[bender at digitalbase dot de]

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

 ID: 53961
 User updated by:bender at digitalbase dot de
 Reported by:bender at digitalbase dot de
 Summary:soap over https with custom port does work
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   WinXP 32bit
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.5-

Win32-VC9-x86

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found

 in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1



C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>cd ..

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.0-

Win32-VC9-x86









C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.0-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(9) of type (Unknown)

}


Previous Comments:

[2011-02-09 13:17:01] cataphr...@php.net

I can't reproduce:



D:\Users\Cataphract\Desktop\php-5.3.5-Win32-VC9-x86>php -d
extension_dir=ext -d

extension=php_soap.dll -d extension=php_openssl.dll -r "$client = new
SoapClient

('https://192.168.4.5:21083/test_13.xml'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(6) of type (Unknown)

}


[2011-02-09 13:01:08] paj...@php.net

and snaps per revision are available at http://rmtools.php.net/snaps/


[2011-02-09 12:57:33] cataphr...@php.net

Re-open as the bug reported missed a "not" in his comment.



Citing the e-mail he sent:



«

> which version does not work? 

PHP 5.3.0 works

PHP 5.3.3 does not work

PHP 5.3.4 does not work

PHP 5.3.5 does not work

> Is it available through windows.php.net?  

Yes,
http://windows.php.net/downloads/releases/php-5.3.5-Win32-VC9-x86.zip

»


[2011-02-09 00:44:34] cataphr...@php.net

Well, if the current version works, I'm closing this bug.


[2011-02-08 19:44:10] bender at digitalbase dot de

the current version does work PHP 5.3.5




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=53961


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

Bug #53961 [Com]: soap over https with custom port does work

[bender at digitalbase dot de]

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

 ID: 53961
 Comment by: bender at digitalbase dot de
 Reported by:bender at digitalbase dot de
 Summary:soap over https with custom port does work
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   WinXP 32bit
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

5.3.0 works

5.3.5 not


Previous Comments:

[2011-02-09 13:26:44] bender at digitalbase dot de

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.5-

Win32-VC9-x86

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found

 in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1



C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>cd ..

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.0-

Win32-VC9-x86









C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.0-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(9) of type (Unknown)

}


[2011-02-09 13:17:01] cataphr...@php.net

I can't reproduce:



D:\Users\Cataphract\Desktop\php-5.3.5-Win32-VC9-x86>php -d
extension_dir=ext -d

extension=php_soap.dll -d extension=php_openssl.dll -r "$client = new
SoapClient

('https://192.168.4.5:21083/test_13.xml'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(6) of type (Unknown)

}


[2011-02-09 13:01:08] paj...@php.net

and snaps per revision are available at http://rmtools.php.net/snaps/


[2011-02-09 12:57:33] cataphr...@php.net

Re-open as the bug reported missed a "not" in his comment.



Citing the e-mail he sent:



«

> which version does not work? 

PHP 5.3.0 works

PHP 5.3.3 does not work

PHP 5.3.4 does not work

PHP 5.3.5 does not work

> Is it available through windows.php.net?  

Yes,
http://windows.php.net/downloads/releases/php-5.3.5-Win32-VC9-x86.zip

»


[2011-02-09 00:44:34] cataphr...@php.net

Well, if the current version works, I'm closing this bug.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=53961


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

Bug #53961 [Opn]: soap over https with custom port does work

[bender at digitalbase dot de]

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

 ID: 53961
 User updated by:bender at digitalbase dot de
 Reported by:bender at digitalbase dot de
 Summary:soap over https with custom port does work
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   WinXP 32bit
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

r308155 from svn has the same error





C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3-ts-

windows-vc9-x86-r308155

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3-ts-

windows-vc9-x86-r308155>php -d extension_dir=ext -d
extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1


Previous Comments:

[2011-02-09 13:27:54] bender at digitalbase dot de

5.3.0 works

5.3.5 not


[2011-02-09 13:26:44] bender at digitalbase dot de

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.5-

Win32-VC9-x86

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found

 in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1



C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>cd ..

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.0-

Win32-VC9-x86









C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.0-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(9) of type (Unknown)

}


[2011-02-09 13:17:01] cataphr...@php.net

I can't reproduce:



D:\Users\Cataphract\Desktop\php-5.3.5-Win32-VC9-x86>php -d
extension_dir=ext -d

extension=php_soap.dll -d extension=php_openssl.dll -r "$client = new
SoapClient

('https://192.168.4.5:21083/test_13.xml'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(6) of type (Unknown)

}


[2011-02-09 13:01:08] paj...@php.net

and snaps per revision are available at http://rmtools.php.net/snaps/


[2011-02-09 12:57:33] cataphr...@php.net

Re-open as the bug reported missed a "not" in his comment.



Citing the e-mail he sent:



«

> which version does not work? 

PHP 5.3.0 works

PHP 5.3.3 does not work

PHP 5.3.4 does not work

PHP 5.3.5 does not work

> Is it available through windows.php.net?  

Yes,
http://windows.php.net/downloads/releases/php-5.3.5-Win32-VC9-x86.zip

»




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=53961


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

Bug #53970 [Com]: PDOStatement::execute returns TRUE even when sql statement is not executed

[lopez at freshsite dot de]

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

 ID: 53970
 Comment by: lopez at freshsite dot de
 Reported by:lopez at freshsite dot de
 Summary:PDOStatement::execute returns TRUE even when sql
 statement is not executed
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Windows
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I recognized, that the error was different, but the expected result is
same.



The sql statement tried to insert a too long string (6 chars) into a too
small field => varchar(2).



However, the execute function should return FALSE, but it doesn't !


Previous Comments:

[2011-02-09 12:04:13] lopez at freshsite dot de

Description:

I recognized, that the return value stay TRUE, even if the sql statement
could not be executed correctly.

Test script:
---
Example:

$sth = $this->db->prepare("REPLACE INTO test

SET bar = 
:foo);

$error = $sth->execute(array('foo' => 'bar'));



/*

$error will be TRUE, because sql is correct and sent.



However, if the mysql user has not the rights (INSERT,DELETE) to do
this, the statement will be not executed at all without error message.



So, don't rely on the returning value until this is fixed!

Expected result:

$error should be FALSE

Actual result:
--
$error is TRUE






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

[PHP-BUG] Bug #53972 [NEW]: Operator Type Casting Issue

[thipse_rahul at rediffmail dot com]

From: 
Operating system: Linux/Windows
PHP version:  5.3.5
Package:  *General Issues
Bug Type: Bug
Bug description:Operator Type Casting Issue

Description:

Following code snippet -- 



Case 1:

$a = (int)((0.1+0.7) * 10); echo $a; // Result: 7 (Wrong) should give 8 



Case 2:

$a = (int)((0.1+0.6) * 10); echo $a; // Result: 7

Case 3:

$a = (int)((0.1+0.8) * 10); echo $a; // Result: 9



Test script:
---
$a = (int)((0.1+0.7) * 10); 

echo $a;







Expected result:

8

Actual result:
--
7

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

Bug #53972 [Opn->Bgs]: Operator Type Casting Issue

[johannes]

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

 ID: 53972
 Updated by: johan...@php.net
 Reported by:thipse_rahul at rediffmail dot com
 Summary:Operator Type Casting Issue
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux/Windows
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
 
Thank you for your interest in PHP.

.


Previous Comments:

[2011-02-09 13:56:31] thipse_rahul at rediffmail dot com

Description:

Following code snippet -- 



Case 1:

$a = (int)((0.1+0.7) * 10); echo $a; // Result: 7 (Wrong) should give 8




Case 2:

$a = (int)((0.1+0.6) * 10); echo $a; // Result: 7

Case 3:

$a = (int)((0.1+0.8) * 10); echo $a; // Result: 9



Test script:
---
$a = (int)((0.1+0.7) * 10); 

echo $a;







Expected result:

8

Actual result:
--
7






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

Bug #53961 [Opn->Fbk]: soap over https with custom port does work

[cataphract]

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

 ID: 53961
 Updated by: cataphr...@php.net
 Reported by:bender at digitalbase dot de
 Summary:soap over https with custom port does work
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:OpenSSL related
 Operating System:   WinXP 32bit
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

If you replace the OpenSSL libs (I think they're named ssleay and
libeay.dll) in the PHP 5.3.5 folder with those bundled with PHP 5.3.0,
do you still get the error?


Previous Comments:

[2011-02-09 13:36:32] bender at digitalbase dot de

r308155 from svn has the same error





C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3-ts-

windows-vc9-x86-r308155

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3-ts-

windows-vc9-x86-r308155>php -d extension_dir=ext -d
extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1


[2011-02-09 13:27:54] bender at digitalbase dot de

5.3.0 works

5.3.5 not


[2011-02-09 13:26:44] bender at digitalbase dot de

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.5-

Win32-VC9-x86

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found

 in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1



C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>cd ..

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.0-

Win32-VC9-x86









C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.0-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(9) of type (Unknown)

}


[2011-02-09 13:17:01] cataphr...@php.net

I can't reproduce:



D:\Users\Cataphract\Desktop\php-5.3.5-Win32-VC9-x86>php -d
extension_dir=ext -d

extension=php_soap.dll -d extension=php_openssl.dll -r "$client = new
SoapClient

('https://192.168.4.5:21083/test_13.xml'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(6) of type (Unknown)

}


[2011-02-09 13:01:08] paj...@php.net

and snaps per revision are available at http://rmtools.php.net/snaps/




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=53961


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

Bug #53961 [Fbk]: soap over https with custom port does work

[cataphract]

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

 ID: 53961
 Updated by: cataphr...@php.net
 Reported by:bender at digitalbase dot de
 Summary:soap over https with custom port does work
 Status: Feedback
 Type:   Bug
 Package:OpenSSL related
 Operating System:   WinXP 32bit
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

Try also swapping ext\php_openssl.dll and ext\php_soap.dll


Previous Comments:

[2011-02-09 14:23:01] cataphr...@php.net

If you replace the OpenSSL libs (I think they're named ssleay and
libeay.dll) in the PHP 5.3.5 folder with those bundled with PHP 5.3.0,
do you still get the error?


[2011-02-09 13:36:32] bender at digitalbase dot de

r308155 from svn has the same error





C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3-ts-

windows-vc9-x86-r308155

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3-ts-

windows-vc9-x86-r308155>php -d extension_dir=ext -d
extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1


[2011-02-09 13:27:54] bender at digitalbase dot de

5.3.0 works

5.3.5 not


[2011-02-09 13:26:44] bender at digitalbase dot de

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.5-

Win32-VC9-x86

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found

 in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1



C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>cd ..

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.0-

Win32-VC9-x86









C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.0-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(9) of type (Unknown)

}


[2011-02-09 13:17:01] cataphr...@php.net

I can't reproduce:



D:\Users\Cataphract\Desktop\php-5.3.5-Win32-VC9-x86>php -d
extension_dir=ext -d

extension=php_soap.dll -d extension=php_openssl.dll -r "$client = new
SoapClient

('https://192.168.4.5:21083/test_13.xml'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(6) of type (Unknown)

}




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=53961


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

Bug #53961 [Fbk->Opn]: soap over https with custom port does work

[bender at digitalbase dot de]

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

 ID: 53961
 User updated by:bender at digitalbase dot de
 Reported by:bender at digitalbase dot de
 Summary:soap over https with custom port does work
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   WinXP 32bit
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

PHP 5.3.5 with php_openssl.dll from PHP 5.3.0 works

(i replace only the php_openssl.dll in the ext dir from 5.3.5)


Previous Comments:

[2011-02-09 14:24:38] cataphr...@php.net

Try also swapping ext\php_openssl.dll and ext\php_soap.dll


[2011-02-09 14:23:01] cataphr...@php.net

If you replace the OpenSSL libs (I think they're named ssleay and
libeay.dll) in the PHP 5.3.5 folder with those bundled with PHP 5.3.0,
do you still get the error?


[2011-02-09 13:36:32] bender at digitalbase dot de

r308155 from svn has the same error





C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3-ts-

windows-vc9-x86-r308155

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3-ts-

windows-vc9-x86-r308155>php -d extension_dir=ext -d
extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1


[2011-02-09 13:27:54] bender at digitalbase dot de

5.3.0 works

5.3.5 not


[2011-02-09 13:26:44] bender at digitalbase dot de

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.5-

Win32-VC9-x86

C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"



Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: 

Couldn't load from 

'https://test.intranet:21081/service/cm/business/Contract/CapacityContract/1.3?

wsdl' : Start tag expected, '<' not found

 in Command line code:1

Stack trace:

#0 Command line code(1): SoapClient->SoapClient('https://ecganwt...')

#1 {main}

  thrown in Command line code on line 1



C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.5-Win32-

VC9-x86>cd ..

C:\Dokumente und Einstellungen\frostm\Eigene Dateien\Downloads>cd
php-5.3.0-

Win32-VC9-x86









C:\Dokumente und Einstellungen\frostm\Eigene
Dateien\Downloads\php-5.3.0-Win32-

VC9-x86>php -d extension_dir=ext -d extension=php_soap.dll -d 

extension=php_openssl.dll -r "$client = new 

SoapClient('https://test.intranet:21081/service/cm/business/Contract/CapacityCon

tract/1.3?wsdl'); var_dump($client);"

object(SoapClient)#1 (2) {

  ["_soap_version"]=>

  int(1)

  ["sdl"]=>

  resource(9) of type (Unknown)

}




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=53961


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

Req #39235 [Asn->Fbk]: Permit parameters in execute()

[andrey]

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

 ID: 39235
 Updated by: and...@php.net
 Reported by:mark dot 2391 at blueyonder dot co dot uk
 Summary:Permit parameters in execute()
-Status: Assigned
+Status: Feedback
 Type:   Feature/Change Request
 Package:MySQLi related
 Operating System:   Debian GNU/Linux
 PHP Version:5.1.6
 Assigned To:mysql
 Block user comment: N
 Private report: N



Previous Comments:

[2011-01-06 15:00:04] u...@php.net

What shall happen to bound parameters after the first execution (error
or not) of the statement? Shall mysqli try to use the same parameters
for a new call to execute even if no values are passed to the execute
method?



  stmt->execute(bound_values) -> OK

  stmt->execute() -> reuse bound_values?



  stmt->execute(bound_values) -> error

  stmt->execute() -> reuse bound_values?



Or:



  stmt->execute(bound_values) -> OK

  stmt->execute() -> error: no values given



What shall happen if parameters have been bound but execute gets called
with new parameters:



  stmt->bind(value) -> use value

  stmt->execute(another_value)  -> use another_value?



Or:



  stmt->bind(value) -> use value

  stmt->execute(another_value)  -> error: must not mix syntax



Ulf


[2006-10-23 13:05:14] mark dot 2391 at blueyonder dot co dot uk

Description:

I want to convert to MySqli from PDO's MySql driver as I'm hitting a
known bug in PDO that isn't getting fixed and I figure MySqli would be
faster anyway.



However, MySqli appears to be restrictive when compared to PDO in its
insistence that I use bind_params(). PDO allows the alternative to pass
Mysql parameters as an array to its execute() method.



My Mysql parameters are passed to me as an array in my code.

I do not know a way in PHP of passing an array of these parameters to
MySQLi while it insists on using bind_params which in turn insists on a
fixed list of named variables.



As I say, PDO copes with this as it's execute() method offers the
alternative choice while params to MySqli's execute() are marked as
void, and so it seems to me impossible to implement my Data Access
Service layer (which manages DB access on similar lines to the PHP SDO
extension) with Mysqli at the moment unless I completely lose the
advantage of prepared statements.



The code below hopefully illustrates the kind of usage I need (and as I
say, PDO allows). Perhaps there is a workaround I have not thought of.



Thanks in advance for any comments/tips,

Mark



Reproduce code:
---
execute($mysqlParams);



class MyDasStmt

{

protected $mysqlParamsStringTypes;

protected $stmt;



public function __construct($dbh, $sql, $mysqlParamsStringTypes)

{

$this->stmt = $dbh->stmt_init();

$this->stmt->prepare($sql);

}



public function execute(array $mysqlParams)

{

$this->stmt->execute($this->mysqlParamsStringTypes,
$mysqlParams);

// ...

}

}

?>



Expected result:

N/A

Actual result:
--
N/A






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

Req #48587 [Asn->Fbk]: MySQL PDO driver doesn't support SSL connections

[andrey]

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

 ID: 48587
 Updated by: and...@php.net
 Reported by:michael dot stringer at yuuguu dot com
 Summary:MySQL PDO driver doesn't support SSL connections
-Status: Assigned
+Status: Feedback
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   *
 PHP Version:5.2.9
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

5.2.* only? If yes, then this will be won't fix.


Previous Comments:

[2010-10-28 09:46:22] u...@php.net

5.2 is closed, http://www.php.net/archive/2010.php#id2010-07-22-1





 The PHP development team would like to announce the immediate
availability of PHP 5.2.14. This release focuses on improving the
stability of the PHP 5.2.x branch with over 60 bug fixes, some of which
are security related.



This release marks the end of the active support for PHP 5.2. Following
this release the PHP 5.2 series will receive no further active bug
maintenance. Security fixes for PHP 5.2 might be published on a case by
cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3


[2009-06-17 15:55:44] michael dot stringer at yuuguu dot com

Description:

The mysqli driver supports connecting to MySQL databases using SSL
certificates via the ssl_set command (which in turn calls the native
client ssl_set function).



Please add this functionality to the PDO driver. This is currently
preventing us from switching from the mysqli APIs to PDO.







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

Req #48587 [Fbk->Asn]: MySQL PDO driver doesn't support SSL connections

[michael dot stringer at yuuguu dot com]

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

 ID: 48587
 User updated by:michael dot stringer at yuuguu dot com
 Reported by:michael dot stringer at yuuguu dot com
 Summary:MySQL PDO driver doesn't support SSL connections
-Status: Feedback
+Status: Assigned
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   *
-PHP Version:5.2.9
+PHP Version:*
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

As of version 5.3.5 this still hasn't been implemented so it is not
limited to 5.2.*


Previous Comments:

[2011-02-09 15:51:10] and...@php.net

5.2.* only? If yes, then this will be won't fix.


[2010-10-28 09:46:22] u...@php.net

5.2 is closed, http://www.php.net/archive/2010.php#id2010-07-22-1





 The PHP development team would like to announce the immediate
availability of PHP 5.2.14. This release focuses on improving the
stability of the PHP 5.2.x branch with over 60 bug fixes, some of which
are security related.



This release marks the end of the active support for PHP 5.2. Following
this release the PHP 5.2 series will receive no further active bug
maintenance. Security fixes for PHP 5.2 might be published on a case by
cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3


[2009-06-17 15:55:44] michael dot stringer at yuuguu dot com

Description:

The mysqli driver supports connecting to MySQL databases using SSL
certificates via the ssl_set command (which in turn calls the native
client ssl_set function).



Please add this functionality to the PDO driver. This is currently
preventing us from switching from the mysqli APIs to PDO.







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

[PHP-BUG] Bug #53973 [NEW]: storing SimpleXMLObject to class property does not always work (is null)

[equinox at lichtspiele dot org]

From: 
Operating system: debian squeeze/sid
PHP version:  5.3.5
Package:  Class/Object related
Bug Type: Bug
Bug description:storing SimpleXMLObject to class property does not always work 
(is null)

Description:

The PHP-Version is 5.3.3-7 (was not able to select this version in the
dropdown box)



When storing a SimpleXMLObject to a class property the property is null
sometimes (every 3rd - 5th call).



According to this error, PHP seems to loose all object descriptors ($this)
in *all* classes, which leads to misleading error messages like "trying to
get property of non-object in ..", even if I checked $this to be an object
1 line before the error message happens (How can $this be not an object? I
am always in object context). 





Current solution: When casting the SimpleXMLObject to an Array and storing
it to the class property both problems do not appear.

Test script:
---
class ProjectXML {



  private $project_xml;



  public function foo((SimpleXMLObject) $xml, $search_criteria) {

// search a specific node, save it to the class property and return
true

$this->project_xml = $xml_node;

return true;

  }



  public function bar() {

var_dump($this->project_xml);

  }



}



$class = new ProjectXML();

$class->foo(simplexml_load_file("/path/to/project.xml"));

$class->bar();



/*

The used code is very complex, so I reduced it to a minimum. The full code
can be viewed here: 

http://quantum-framework.org/ProjectXML.class.phps

*/

Expected result:

SimpleXMLObject

Actual result:
--
sometimes null

sometimes the SimpleXMLObject

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

Bug #53972 [Com]: Operator Type Casting Issue

[anon at anon dot anon]

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

 ID: 53972
 Comment by: anon at anon dot anon
 Reported by:thipse_rahul at rediffmail dot com
 Summary:Operator Type Casting Issue
 Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux/Windows
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

PHP guys, will you please stop giving people broken links?


Previous Comments:

[2011-02-09 14:18:33] johan...@php.net

Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
 
Thank you for your interest in PHP.

.


[2011-02-09 13:56:31] thipse_rahul at rediffmail dot com

Description:

Following code snippet -- 



Case 1:

$a = (int)((0.1+0.7) * 10); echo $a; // Result: 7 (Wrong) should give 8




Case 2:

$a = (int)((0.1+0.6) * 10); echo $a; // Result: 7

Case 3:

$a = (int)((0.1+0.8) * 10); echo $a; // Result: 9



Test script:
---
$a = (int)((0.1+0.7) * 10); 

echo $a;







Expected result:

8

Actual result:
--
7






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

Bug #53971 [Opn->Bgs]: isset() and empty() produce apparently spurious runtime error

[dtajchreber]

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

 ID: 53971
 Updated by: dtajchre...@php.net
 Reported by:david at frankieandshadow dot com
 Summary:isset() and empty() produce apparently spurious
 runtime error
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Arrays related
 Operating System:   Linux, Redhat Enterprise
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

$obj->m is an empty string. You try to access a non-integer offset.
Non-integer 

offsets are converted to 

integers. So in other words:

$obj->m['a'] becomes $obj->m[0]

$obj->m is an empty string and $obj->m[0] doesn't exist

This behavior is documented here: 

http://us.php.net/manual/en/language.types.string.php



"Warning

Writing to an out of range offset pads the string with spaces.
Non-integer types 

are converted to integer. 

Illegal offset type emits E_NOTICE. Negative offset emits E_NOTICE in
write but 

reads empty string. Only the 

first character of an assigned string is used. Assigning empty string
assigns 

NUL byte."



Simplifying the problem: http://codepad.org/G31wr4oJ


Previous Comments:

[2011-02-09 13:12:44] david at frankieandshadow dot com

Description:

First, apologies, this is 5.3.3. I have no means of upgrading to check
whether 

this is a fixed issue. I can't see anything similar in the bug
database.



An expression of the form 

  isset($obj->m['a']['b'])

produces a runtime error when m is not actually an array but a zero
length 

string:

  Uninitialized string offset: 0

The same is the case if I use empty instead of isset.

The same code worked in 5.2. Changing it to 

  isset($obj->m['a']) && isset($obj->m['a']['b'])

works.



isset is not supposed to produce any runtime error, surely, in this kind
of use.



The object member values arise from a database lookup, and normally the
field (m 

above) will be a serialized array in the database, but the first time
the 

database column will be empty, leading to an empty string assignment to
m. In 

addition once populated the object is stored in $_SESSION (actually in 

$_SESSION['p']['q']) and then $obj is obtained by assignment from the
session, 

like this

  $session =& $_SESSION['p']; // where $_SESSION['p'] is set in a
previous page

  // populate new $obj1 from database

  $session['q'] = $obj1;

  ...

  $obj =& $session['q'];

and the offending code is then executed elsewhere some time later.



However, abstracting the code from this much bigger program does not
demonstrate 

the problem, which suggests to me something is corrupted somewhere. This
is what 

I tried on its own, which is as close as I can reasonably get to the
situation 

here, but it works. (The =& are leftovers from what was originally a
PHP4 app; I 

know all objects are assigned by reference in PHP5).



class c { var $m; }



session_start();

if (! isset($_SESSION['p'])) {

  $_SESSION['p'] = array();

  echo "set session array";

  exit;

}

$session =& $_SESSION['p'];

$obj1 = new c();

$obj1->m = '';

$session['q'] = $obj1;

$obj =& $session['q'];

function check() {

  global $obj;

  echo (isset($obj->m['a']['b']) ? 'Yes' : 'No');

}

check();

Expected result:

isset to return FALSE

Actual result:
--
runtime error

Uninitialized string offset: 0






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

Bug #53844 [Com]: PHP built from source on Solaris gets SIGSEGV with libiconv

[phil at quizlet dot com]

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

 ID: 53844
 Comment by: phil at quizlet dot com
 Reported by:r at rcrowley dot org
 Summary:PHP built from source on Solaris gets SIGSEGV with
 libiconv
 Status: Feedback
 Type:   Bug
 Package:ICONV related
 Operating System:   Solaris
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

I ran it exactly as you wrote, still got a "Segmentation Fault (core
dumped)"



[root@gnp2b7ap /opt/sourceinstall/php-5.3.5]# /root/gdb/bin/gdb
./sapi/cli/php 

core

GNU gdb 6.2.1

Copyright 2004 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you
are

welcome to change it and/or distribute copies of it under certain
conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for
details.

This GDB was configured as "i386-sun-solaris2"...

Core was generated by `./sapi/cli/php -r echo iconv("UTF-8", "UTF-8",
"Hello, 

world.\n");'.

Program terminated with signal 11, Segmentation fault.

Reading symbols from /lib/libresolv.so.2...done.

Loaded symbols for /lib/libresolv.so.2

Reading symbols from /opt/local/lib/libiconv.so.2...done.

Loaded symbols for /opt/local/lib/libiconv.so.2

Reading symbols from /lib/librt.so.1...

warning: Lowest section in /lib/librt.so.1 is .dynamic at 0074

done.

Loaded symbols for /lib/librt.so.1

Reading symbols from /lib/libm.so.2...done.

Loaded symbols for /lib/libm.so.2

Reading symbols from /lib/libnsl.so.1...done.

Loaded symbols for /lib/libnsl.so.1

Reading symbols from /lib/libsocket.so.1...done.

Loaded symbols for /lib/libsocket.so.1

Reading symbols from /lib/libc.so.1...done.

Loaded symbols for /lib/libc.so.1

Reading symbols from /opt/gcc/lib/libgcc_s.so.1...done.

Loaded symbols for /opt/gcc/lib/libgcc_s.so.1

Reading symbols from /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-

1.so.3...done.

Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.3

#0  0xec835356 in ?? ()

(gdb) bt

#0  0xec835356 in ?? ()

#1  0xfebc68ab in iconv () from /lib/libc.so.1

#2  0x080d9141 in php_iconv_string (in_p=0x8308488 "Hello, world.\n",
in_len=14, 

out=0x8047624, out_len=0x8047628, out_charset=0x830845c "UTF-8", 

in_charset=0x8309904 "UTF-8")

at /opt/sourceinstall/php-5.3.5/ext/iconv/iconv.c:501

#3  0x080dbb0c in php_if_iconv (ht=3, return_value=0x83084a0, 

return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 

/opt/sourceinstall/php-

5.3.5/ext/iconv/iconv.c:2327

#4  0x081caac5 in zend_do_fcall_common_helper_SPEC
(execute_data=0x83ec520) at 

zend_vm_execute.h:316

#5  0x081c9ec2 in execute (op_array=0x8308388) at zend_vm_execute.h:107

#6  0x081a1e3f in zend_eval_stringl (str=0x8047ce6 "echo
iconv(\"UTF-8\", \"UTF-

8\", \"Hello, world.\\n\");", str_len=0, retval_ptr=0x0,
string_name=0x82b9ec9 

"Command line code")

at /opt/sourceinstall/php-5.3.5/Zend/zend_execute_API.c:1193

#7  0x081a1fdb in zend_eval_stringl_ex (str=0x8047ce6 "echo
iconv(\"UTF-8\", 

\"UTF-8\", \"Hello, world.\\n\");", str_len=48, retval_ptr=0x0, 

string_name=0x82b9ec9 "Command line code", 

handle_exceptions=1) at /opt/sourceinstall/php-

5.3.5/Zend/zend_execute_API.c:1235

#8  0x081a2035 in zend_eval_string_ex (str=0x80475e0 "\016",
retval_ptr=0x0, 

string_name=0x82b9ec9 "Command line code", handle_exceptions=1)

at /opt/sourceinstall/php-5.3.5/Zend/zend_execute_API.c:1246

#9  0x08223584 in main (argc=3, argv=0x8047bf0) at
/opt/sourceinstall/php-

5.3.5/sapi/cli/php_cli.c:1282


Previous Comments:

[2011-02-09 11:34:09] johan...@php.net

I meant to write --disable-all, sorry for the mistake. Could you try



   ./configure --disable-all --with-iconv && make && ./sapi/cli/php -r
'echo iconv("UTF-8", "UTF-8", "Hello, world.\n");'


[2011-02-09 01:15:59] phil at quizlet dot com

No luck...



With the original configuration, I tried:



# LD_LIBRARY_PATH=/opt/local/lib ; export LD_LIBRARY_PATH ; php -r 'echo


iconv("UTF-8", "UTF-8", "Hello, world.\n");'



as well as:



# LD_LIBRARY_PATH=/opt/local/lib php -r 'echo iconv("UTF-8", "UTF-8",
"Hello, 

world.\n");'



as well as reconfiguring with:



# ./configure --disable-iconv --with-iconv



and also tried:



# ./configure LDFLAGS=/opt/local/lib --with-iconv



and:



# ./configure LDFLAGS=/opt/local/lib --disable-iconv --with-iconv



Note: I did get a "Notice: Following unknown configure options were
used: --

disable-iconv" when trying to follow johannes advice, and
--disable-iconv isn't 

listed in ./configure --help.



In ALL of the above cases when testing PHP's iconv() I got a segfault
and 

checked the backtrace with gdb after each and they were all identi

[PHP-BUG] Bug #53974 [NEW]: Crash in trunk zend_dtoa() with unmet loop condition

[s...@php.net]

From: sixd
Operating system: Ubuntu 32 bit
PHP version:  trunk-SVN-2011-02-09 (SVN)
Package:  *General Issues
Bug Type: Bug
Bug description:Crash in trunk zend_dtoa() with unmet loop condition

Description:

A segfault occurs after a few reloads of a phpinfo() script with PHP trunk
on Ubuntu 10.04 and 10.10, both 32bit.  It doesn't occur with PHP_5_3.



Test script:
---
Steps:

- Start Apache: httpd -x

- Repeatedly load a script .

- Within 10 reloads, Apache segfaults.

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.

0x009064ae in zend_dtoa (_d=197618504, mode=2, ndigits=14,
decpt=0xbfffc8cc, sign=0xbfffc8c8, rve=0x0) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_strtod.c:1670

(gdb) bt

#0  0x009064ae in zend_dtoa (_d=197618504, mode=2, ndigits=14,
decpt=0xbfffc8cc, sign=0xbfffc8c8, rve=0x0) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_strtod.c:1670

#1  0x0086d374 in php_gcvt (value=197618504, ndigit=14, dec_point=46 '.',
exponent=69 'E', buf=0xbfffc9cd "5\217") at
/home/cjones/phpsrc/php/php-src/trunk/main/snprintf.c:142

#2  0x008703a5 in xbuf_format_converter (xbuf=0xbfffcbf4, fmt=0xcfb477 "G",
ap=0xbfffcc58 "_(\210") at
/home/cjones/phpsrc/php/php-src/trunk/main/spprintf.c:669

#3  0x00870db5 in vspprintf (pbuf=0xbfffcd04, max_len=0, format=0xcfb474
"%.*G", ap=0xbfffcc4c "\016") at
/home/cjones/phpsrc/php/php-src/trunk/main/spprintf.c:797

#4  0x00903c63 in zend_spprintf (message=0xbfffcd04, max_len=0,
format=0xcfb474 "%.*G") at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_exceptions.c:545

#5  0x008dc2ec in _convert_to_string (op=0xbfffcd04,
__zend_filename=0xccd72c
"/home/cjones/phpsrc/php/php-src/trunk/ext/standard/info.c",
__zend_lineno=252) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_operators.c:578

#6  0x007b4fc3 in php_print_gpcse_array (name=0xcce134 "_SERVER",
name_length=7) at
/home/cjones/phpsrc/php/php-src/trunk/ext/standard/info.c:252

#7  0x007b5e46 in php_print_info (flag=-1) at
/home/cjones/phpsrc/php/php-src/trunk/ext/standard/info.c:885

#8  0x007b66d4 in zif_phpinfo (ht=0, return_value=0xb7fc1734,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at
/home/cjones/phpsrc/php/php-src/trunk/ext/standard/info.c:1141

#9  0x0091a7d0 in zend_do_fcall_common_helper_SPEC
(execute_data=0xb7fa6074) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_vm_execute.h:638

#10 0x0091fac5 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xb7fa6074) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_vm_execute.h:1935

#11 0x00919632 in execute (op_array=0xb7fc0808) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_vm_execute.h:410

#12 0x008e629e in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /home/cjones/phpsrc/php/php-src/trunk/Zend/zend.c:1212

#13 0x0086cc4f in php_execute_script (primary_file=0xb3ac) at
/home/cjones/phpsrc/php/php-src/trunk/main/main.c:2344

#14 0x009ed1f8 in php_handler (r=0x83299c8) at
/home/cjones/phpsrc/php/php-src/trunk/sapi/apache2handler/sapi_apache2.c:667

#15 0x0807c556 in ap_run_handler (r=0x83299c8) at config.c:158

#16 0x0807fc01 in ap_invoke_handler (r=0x83299c8) at config.c:372

#17 0x080974e0 in ap_process_request (r=0x83299c8) at http_request.c:282

#18 0x08094520 in ap_process_http_connection (c=0x8323b48) at
http_core.c:190

#19 0x08083fe6 in ap_run_process_connection (c=0x8323b48) at
connection.c:43

#20 0x080b472d in child_main (child_num_arg=) at
prefork.c:662

#21 0x080b49df in make_child (s=0x80e5db8, slot=0) at prefork.c:702

#22 0x080b509c in ap_mpm_run (_pconf=0x80df0a8, plog=0x811d1a0,
s=0x80e5db8) at prefork.c:978

#23 0x08069134 in main (argc=2, argv=0xb8f4) at main.c:740

(gdb) p j1

$1 = -2147483648

(gdb) p j

$2 = -1

(gdb) p *decpt

$3 = 9154443

(gdb) p *sign

$4 = 0

(gdb) p i

$5 = 4678168

(gdb) p d

$6 = {

  d = nan(0xf),

  ul = {4294967295, 2147483647}

}



The crash is at the assignment of bigtens[i] in:



else if ((j1 = -k)) {

value(d) *= tens[j1 & 0xf];

for(j = j1 >> 4; j; j >>= 1, i++)

if (j & 1) {

ieps++;

value(d) *= bigtens[i];

}

}



Because j is -1 it can never satisfy the loop condition



The relevant code in the file is unchanged from PHP 5.3 and dropping in PHP
5.3 zend_strtod.[ch] files into trunk and rebuilding doesn't fix it.



-- 
Edit bug report at http://bugs.php.net/bug.php?id=53974&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53974&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53974&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=53974&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53974&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=53974&r=needdocs
Fixed in release:
http:/

Bug #53974 [Opn->Asn]: Crash in trunk zend_dtoa() with unmet loop condition

[johannes]

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

 ID: 53974
 Updated by: johan...@php.net
 Reported by:s...@php.net
 Summary:Crash in trunk zend_dtoa() with unmet loop condition
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   Ubuntu 32 bit
 PHP Version:trunk-SVN-2011-02-09 (SVN)
-Assigned To:
+Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Dmitry, any idea maybe?


Previous Comments:

[2011-02-09 20:22:18] s...@php.net

Description:

A segfault occurs after a few reloads of a phpinfo() script with PHP
trunk on Ubuntu 10.04 and 10.10, both 32bit.  It doesn't occur with
PHP_5_3.



Test script:
---
Steps:

- Start Apache: httpd -x

- Repeatedly load a script .

- Within 10 reloads, Apache segfaults.

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.

0x009064ae in zend_dtoa (_d=197618504, mode=2, ndigits=14,
decpt=0xbfffc8cc, sign=0xbfffc8c8, rve=0x0) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_strtod.c:1670

(gdb) bt

#0  0x009064ae in zend_dtoa (_d=197618504, mode=2, ndigits=14,
decpt=0xbfffc8cc, sign=0xbfffc8c8, rve=0x0) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_strtod.c:1670

#1  0x0086d374 in php_gcvt (value=197618504, ndigit=14, dec_point=46
'.', exponent=69 'E', buf=0xbfffc9cd "5\217") at
/home/cjones/phpsrc/php/php-src/trunk/main/snprintf.c:142

#2  0x008703a5 in xbuf_format_converter (xbuf=0xbfffcbf4, fmt=0xcfb477
"G", ap=0xbfffcc58 "_(\210") at
/home/cjones/phpsrc/php/php-src/trunk/main/spprintf.c:669

#3  0x00870db5 in vspprintf (pbuf=0xbfffcd04, max_len=0, format=0xcfb474
"%.*G", ap=0xbfffcc4c "\016") at
/home/cjones/phpsrc/php/php-src/trunk/main/spprintf.c:797

#4  0x00903c63 in zend_spprintf (message=0xbfffcd04, max_len=0,
format=0xcfb474 "%.*G") at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_exceptions.c:545

#5  0x008dc2ec in _convert_to_string (op=0xbfffcd04,
__zend_filename=0xccd72c
"/home/cjones/phpsrc/php/php-src/trunk/ext/standard/info.c",
__zend_lineno=252) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_operators.c:578

#6  0x007b4fc3 in php_print_gpcse_array (name=0xcce134 "_SERVER",
name_length=7) at
/home/cjones/phpsrc/php/php-src/trunk/ext/standard/info.c:252

#7  0x007b5e46 in php_print_info (flag=-1) at
/home/cjones/phpsrc/php/php-src/trunk/ext/standard/info.c:885

#8  0x007b66d4 in zif_phpinfo (ht=0, return_value=0xb7fc1734,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at
/home/cjones/phpsrc/php/php-src/trunk/ext/standard/info.c:1141

#9  0x0091a7d0 in zend_do_fcall_common_helper_SPEC
(execute_data=0xb7fa6074) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_vm_execute.h:638

#10 0x0091fac5 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xb7fa6074) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_vm_execute.h:1935

#11 0x00919632 in execute (op_array=0xb7fc0808) at
/home/cjones/phpsrc/php/php-src/trunk/Zend/zend_vm_execute.h:410

#12 0x008e629e in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/cjones/phpsrc/php/php-src/trunk/Zend/zend.c:1212

#13 0x0086cc4f in php_execute_script (primary_file=0xb3ac) at
/home/cjones/phpsrc/php/php-src/trunk/main/main.c:2344

#14 0x009ed1f8 in php_handler (r=0x83299c8) at
/home/cjones/phpsrc/php/php-src/trunk/sapi/apache2handler/sapi_apache2.c:667

#15 0x0807c556 in ap_run_handler (r=0x83299c8) at config.c:158

#16 0x0807fc01 in ap_invoke_handler (r=0x83299c8) at config.c:372

#17 0x080974e0 in ap_process_request (r=0x83299c8) at
http_request.c:282

#18 0x08094520 in ap_process_http_connection (c=0x8323b48) at
http_core.c:190

#19 0x08083fe6 in ap_run_process_connection (c=0x8323b48) at
connection.c:43

#20 0x080b472d in child_main (child_num_arg=) at
prefork.c:662

#21 0x080b49df in make_child (s=0x80e5db8, slot=0) at prefork.c:702

#22 0x080b509c in ap_mpm_run (_pconf=0x80df0a8, plog=0x811d1a0,
s=0x80e5db8) at prefork.c:978

#23 0x08069134 in main (argc=2, argv=0xb8f4) at main.c:740

(gdb) p j1

$1 = -2147483648

(gdb) p j

$2 = -1

(gdb) p *decpt

$3 = 9154443

(gdb) p *sign

$4 = 0

(gdb) p i

$5 = 4678168

(gdb) p d

$6 = {

  d = nan(0xf),

  ul = {4294967295, 2147483647}

}



The crash is at the assignment of bigtens[i] in:



else if ((j1 = -k)) {

value(d) *= tens[j1 & 0xf];

for(j = j1 >> 4; j; j >>= 1, i++)

if (j & 1) {

ieps++;

value(d) *= bigtens[i];

}

}



Because j is -1 it can never satisfy the loop condition



The relevant code in the file is unchanged from PHP 5.3 and dropping in
PHP 5.3 zend_strtod.[ch] files into trunk and rebuilding doesn't fix
it.








-- 
Edit 

Bug #53971 [Bgs]: isset() and empty() produce apparently spurious runtime error

[david at frankieandshadow dot com]

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

 ID: 53971
 User updated by:david at frankieandshadow dot com
 Reported by:david at frankieandshadow dot com
 Summary:isset() and empty() produce apparently spurious
 runtime error
 Status: Bogus
 Type:   Bug
 Package:Arrays related
 Operating System:   Linux, Redhat Enterprise
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

I appreciate that this is the case. When you say "$obj->m[0] doesn't
exist", yes 

I agree, BUT that is what the isset is testing for.



If it SHOULD produce a runtime error, then (a) this is a very subtle
non-upwards 

compatible change from 5.2, and (b) the example I quoted does NOT
produce a 

runtime error so is a bug.



(And producing a runtime error in these circumstances is terribly
inconvenient, 

it means you can't test existence in one go but have to try each element


individually).



If it SHOULD NOT produce a runtime error then there is a problem with
the larger 

code I have which follows this pattern and is doing so.



There is a bug here one way or the other: either my larger program is
wrong (but 

has worked for years with this code in it) or the example I put in the
bug 

report is wrong in that it does not produce an error and never has. At
present 

the behaviour is inconsistent.


Previous Comments:

[2011-02-09 17:50:29] dtajchre...@php.net

$obj->m is an empty string. You try to access a non-integer offset.
Non-integer 

offsets are converted to 

integers. So in other words:

$obj->m['a'] becomes $obj->m[0]

$obj->m is an empty string and $obj->m[0] doesn't exist

This behavior is documented here: 

http://us.php.net/manual/en/language.types.string.php



"Warning

Writing to an out of range offset pads the string with spaces.
Non-integer types 

are converted to integer. 

Illegal offset type emits E_NOTICE. Negative offset emits E_NOTICE in
write but 

reads empty string. Only the 

first character of an assigned string is used. Assigning empty string
assigns 

NUL byte."



Simplifying the problem: http://codepad.org/G31wr4oJ


[2011-02-09 13:12:44] david at frankieandshadow dot com

Description:

First, apologies, this is 5.3.3. I have no means of upgrading to check
whether 

this is a fixed issue. I can't see anything similar in the bug
database.



An expression of the form 

  isset($obj->m['a']['b'])

produces a runtime error when m is not actually an array but a zero
length 

string:

  Uninitialized string offset: 0

The same is the case if I use empty instead of isset.

The same code worked in 5.2. Changing it to 

  isset($obj->m['a']) && isset($obj->m['a']['b'])

works.



isset is not supposed to produce any runtime error, surely, in this kind
of use.



The object member values arise from a database lookup, and normally the
field (m 

above) will be a serialized array in the database, but the first time
the 

database column will be empty, leading to an empty string assignment to
m. In 

addition once populated the object is stored in $_SESSION (actually in 

$_SESSION['p']['q']) and then $obj is obtained by assignment from the
session, 

like this

  $session =& $_SESSION['p']; // where $_SESSION['p'] is set in a
previous page

  // populate new $obj1 from database

  $session['q'] = $obj1;

  ...

  $obj =& $session['q'];

and the offending code is then executed elsewhere some time later.



However, abstracting the code from this much bigger program does not
demonstrate 

the problem, which suggests to me something is corrupted somewhere. This
is what 

I tried on its own, which is as close as I can reasonably get to the
situation 

here, but it works. (The =& are leftovers from what was originally a
PHP4 app; I 

know all objects are assigned by reference in PHP5).



class c { var $m; }



session_start();

if (! isset($_SESSION['p'])) {

  $_SESSION['p'] = array();

  echo "set session array";

  exit;

}

$session =& $_SESSION['p'];

$obj1 = new c();

$obj1->m = '';

$session['q'] = $obj1;

$obj =& $session['q'];

function check() {

  global $obj;

  echo (isset($obj->m['a']['b']) ? 'Yes' : 'No');

}

check();

Expected result:

isset to return FALSE

Actual result:
--
runtime error

Uninitialized string offset: 0






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

[PHP-BUG] Req #53975 [NEW]: Late constant define (class const to class name translation)

[landeholm at gmail dot com]

From: 
Operating system: Irrelevant
PHP version:  5.3.5
Package:  Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Late constant define (class const to class name translation)

Description:

Hello,



I'm making a framework which utilizes namespaces and classes. One thing I
like with PHP is how you can work with class names like normal strings.
There's no special "Type" or "ClassType" object that wraps this behavior
and identifies a particular class. A handle to a class is simply a string
with the same name. All good and well. So you start to juggle with class
names and makes functions that accept the names of classes. One thing I do
in my framework is giving the ability to preinitialize objects in classes
with the class you define. Like:



namespace misc\some_ns;



class Foo extends Something {

public $bar = "misc\some_ns\Baz";

}



I do this since PHP doesn't allow object instances ( = new Baz()) as the
default value of object variables. I understand that this would be
problematic since for example get_class_vars etc would have to instantiate
class objects in it's return values. Implicit object construction can
result in undesired side-effects.



I also work with class names in a bunch of other ways. An annoyance however
is that the class name in a string is naturally not affected by the current
namespace you're in, requiring you to literally have to "think out of the
box" whenever you type a class name. Also since you're typing inside of a
string there's no auto completion. Removing the quotes I can CTRL+Space (in
netbeans) the smart resolved class name in no time, but adding the quotes
requires you to type the full class name without any help.



This is basically how I'd rather want to express the above which is much
cleaner and better understood by IDE's (I could for example track the
references of the Baz class and see that it's used on this line):



namespace misc\some_ns;



class Foo extends Something {

public $bar = Baz;

}



It's unfair, really, that PHP identifiers like new, clone, instanceof etc
gets to use the magic and awesome namespace aware string-less direct class
name resolving. Why not allow this behavior in any context and not just in
the presence of these identifiers? You can already juggle with class names
in strings and use strings dynamically with these identifiers, so
implementing automatic class-identifier-to-full-classname resolving would
be in spirit with the existing behavior.



To implement this, change the way constants are resolved to:



1. If constants exists with same name return constant value.



2. *new* If namespace aware class exists return full class name.



3. Return constant name as string and trigger "assuming constant name"
error.



The obvious problem with this however is that it would not be compatible
with autoloading. Probing the autoloader can be dangerous as some autoload
implementations might throw exceptions/errors/halt the script etc if the
class name doesn't exist. In fact the official autoload documentation
suggests this.



Therefore I like to suggest a completely different implementation of this
solution that not only enables constant class name resolving with autoload
support but increase flexibility greatly when designing frameworks:
automatic late constant define. By allowing the programmer to define
constants as they are used (much the same way classes are defined when they
are first used with autoload) this behavior and many other unspecified
late-constant binding behaviors could be implemented.



Example:



Take the constant resolution steps above but changed to the following:



1. If constants exists with same name return constant value.



2. *new* Invoke SPL constant "autodefine" function stack. If one of them
return a value for it the constant is defined with that value.



3. Return constant name as string and trigger "assuming constant name"
error.



The following new functions would be implemented: (for example)



spl_autodefine_call( string $name )

spl_autodefine_functions( void )

spl_autodefine_register( callback $autodefine_function [, bool $prepend =
false ]] )

spl_autodefine_unregister( callback $autodefine_function )



These would work much the same way as the spl_autoloads but be used for
constant resolving instead. By default the autodefine function stack would
be empty and 2. be skipped. If a function has been registered with
spl_autodefine_register(), that function will be called with the constant
name as it's first and only argument. The function can now choose to
declare this constant or not. The return value is ignored. [[One possible
implementation would be to declare the constant with the return value and
use NULL as a placeholder if the function don't understand the constant.
But then a constant could not be declared as NULL.]] If the function did
not declare the constant the next function is called.



The normal resolutio

[PHP-BUG] Bug #53976 [NEW]: running phpunit causes seg fault in php garbage collection

[matthew dot scott dot day at gmail dot com]

From: 
Operating system: ubuntu 10.10
PHP version:  5.3.5
Package:  Reproducible crash
Bug Type: Bug
Bug description:running phpunit causes seg fault in php garbage collection

Description:

FIRST TEST

---





root@matthewbox:/pool/www/www.example.com/tests# USE_ZEND_ALLOC=0 gdb php

GNU gdb (GDB) 7.2-ubuntu

Copyright (C) 2010 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 "x86_64-linux-gnu".

For bug reporting instructions, please see:

...

Reading symbols from /usr/local/bin/php...done.

(gdb) run -dzend.enable_gc=0 /usr/local/bin/phpunit --coverage-html
../public/tests/

Starting program: /usr/local/bin/php -dzend.enable_gc=0
/usr/local/bin/phpunit --coverage-html ../public/tests/

[Thread debugging using libthread_db enabled]

PHPUnit 3.5.10 by Sebastian Bergmann.



[New Thread 0x724a6700 (LWP 17827)]

[Thread 0x724a6700 (LWP 17827) exited]





Time: 26 seconds, Memory: 0.25Mb



OK (20 tests, 20 assertions)



Generating code coverage report, this may take a moment.



Program received signal SIGSEGV, Segmentation fault.

gc_remove_zval_from_buffer (zv=) at
/home/matthew/src/php-5.3.5/Zend/zend_gc.c:265

265 GC_REMOVE_FROM_BUFFER(root_buffer);















(gdb) run -dzend.enable_gc=0 /usr/local/bin/phpunit --coverage-html
../public/tests/

The program being debugged has been started already.

Start it from the beginning? (y or n) y

Starting program: /usr/local/bin/php -dzend.enable_gc=0
/usr/local/bin/phpunit --coverage-html ../public/tests/

[Thread debugging using libthread_db enabled]

PHPUnit 3.5.10 by Sebastian Bergmann.



[New Thread 0x724a6700 (LWP 17839)]

[Thread 0x724a6700 (LWP 17839) exited]





Time: 25 seconds, Memory: 0.25Mb



OK (20 tests, 20 assertions)



Generating code coverage report, this may take a moment.



Program received signal SIGSEGV, Segmentation fault.

0x0075a571 in gc_zval_possible_root (zv=0x37dadf0) at
/home/matthew/src/php-5.3.5/Zend/zend_gc.c:143

143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);

(gdb) bt

#0  0x0075a571 in gc_zval_possible_root (zv=0x37dadf0) at
/home/matthew/src/php-5.3.5/Zend/zend_gc.c:143

#1  0x0074912b in zend_hash_destroy (ht=0x37daf50) at
/home/matthew/src/php-5.3.5/Zend/zend_hash.c:529

#2  0x0075bb89 in zend_object_std_dtor (object=0x37edb00) at
/home/matthew/src/php-5.3.5/Zend/zend_objects.c:45

#3  0x0075bba9 in zend_objects_free_object_storage
(object=0x37dadf0) at /home/matthew/src/php-5.3.5/Zend/zend_objects.c:126

#4  0x0075f888 in zend_objects_store_del_ref_by_handle_ex
(handle=, handlers=) at
/home/matthew/src/php-5.3.5/Zend/zend_objects_API.c:220

#5  0x0075f8a3 in zend_objects_store_del_ref (zobject=0x37dee20) at
/home/matthew/src/php-5.3.5/Zend/zend_objects_API.c:172

#6  0x0073072d in _zval_dtor (zval_ptr=0x3814058) at
/home/matthew/src/php-5.3.5/Zend/zend_variables.h:35

#7  _zval_ptr_dtor (zval_ptr=0x3814058) at
/home/matthew/src/php-5.3.5/Zend/zend_execute_API.c:443

#8  0x0074912b in zend_hash_destroy (ht=0x3814160) at
/home/matthew/src/php-5.3.5/Zend/zend_hash.c:529

#9  0x0073c2cf in _zval_dtor_func (zvalue=0x37decb0) at
/home/matthew/src/php-5.3.5/Zend/zend_variables.c:43

#10 0x0073072d in _zval_dtor (zval_ptr=0x3779148) at
/home/matthew/src/php-5.3.5/Zend/zend_variables.h:35

#11 _zval_ptr_dtor (zval_ptr=0x3779148) at
/home/matthew/src/php-5.3.5/Zend/zend_execute_API.c:443

#12 0x0074912b in zend_hash_destroy (ht=0x36ff340) at
/home/matthew/src/php-5.3.5/Zend/zend_hash.c:529

#13 0x0075bb89 in zend_object_std_dtor (object=0x367e300) at
/home/matthew/src/php-5.3.5/Zend/zend_objects.c:45

#14 0x0075bba9 in zend_objects_free_object_storage
(object=0x37dadf0) at /home/matthew/src/php-5.3.5/Zend/zend_objects.c:126

#15 0x0075f3a8 in zend_objects_store_free_object_storage
(objects=0xef86b8) at
/home/matthew/src/php-5.3.5/Zend/zend_objects_API.c:92

#16 0x00730b25 in shutdown_executor () at
/home/matthew/src/php-5.3.5/Zend/zend_execute_API.c:302

#17 0x0073d042 in zend_deactivate () at
/home/matthew/src/php-5.3.5/Zend/zend.c:890

#18 0x006ea665 in php_request_shutdown (dummy=) at /home/matthew/src/php-5.3.5/main/main.c:1633

#19 0x007c60cc in main (argc=, argv=) at /home/matthew/src/php-5.3.5/sapi/cli/php_cli.c:1374

(gdb) 





































THIRD TEST

-



(gdb) run -dzend.enable_gc=0 /usr/local/bin/phpunit --coverage-html
../public/tests/

The program being debugged has been started alr

Bug #53844 [Fbk]: PHP built from source on Solaris gets SIGSEGV with libiconv

[srinatar]

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

 ID: 53844
 Updated by: srina...@php.net
 Reported by:r at rcrowley dot org
 Summary:PHP built from source on Solaris gets SIGSEGV with
 libiconv
 Status: Feedback
 Type:   Bug
 Package:ICONV related
 Operating System:   Solaris
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

As Johannes and the core dump output show this has nothing to do with
php core. this is a compilation issue mainly due to the way your
environment is set up. 



this is what i did



- unset LD_LIBRARY_PATH

- installed libiconv in /opt/local

- compiled php as ./configure --disable-all --with-iconv=/opt/local

- ldd sapi/cli/php | grep iconv and verify that PHP is depending on
/opt/local/lib

- ./sapi/cli/php -r 'echo iconv("UTF-8", "UTF-8", "Hello, world.\n");'



and got the expected results..



note: i did use the OS provided gcc for my compilation needs. 



pl. note that i see that you have compiled and installed other dependent
libraries at /opt/local as well. you might want to ensure that when you
compiled those - they all depend on /opt/local/lib as well. it is not a
good idea to mix between OS provided iconv libraries vs what you
compiled.



i would like to close this bug as not a valid bug if others don't have
any issue.


Previous Comments:

[2011-02-09 19:00:50] phil at quizlet dot com

I ran it exactly as you wrote, still got a "Segmentation Fault (core
dumped)"



[root@gnp2b7ap /opt/sourceinstall/php-5.3.5]# /root/gdb/bin/gdb
./sapi/cli/php 

core

GNU gdb 6.2.1

Copyright 2004 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you
are

welcome to change it and/or distribute copies of it under certain
conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for
details.

This GDB was configured as "i386-sun-solaris2"...

Core was generated by `./sapi/cli/php -r echo iconv("UTF-8", "UTF-8",
"Hello, 

world.\n");'.

Program terminated with signal 11, Segmentation fault.

Reading symbols from /lib/libresolv.so.2...done.

Loaded symbols for /lib/libresolv.so.2

Reading symbols from /opt/local/lib/libiconv.so.2...done.

Loaded symbols for /opt/local/lib/libiconv.so.2

Reading symbols from /lib/librt.so.1...

warning: Lowest section in /lib/librt.so.1 is .dynamic at 0074

done.

Loaded symbols for /lib/librt.so.1

Reading symbols from /lib/libm.so.2...done.

Loaded symbols for /lib/libm.so.2

Reading symbols from /lib/libnsl.so.1...done.

Loaded symbols for /lib/libnsl.so.1

Reading symbols from /lib/libsocket.so.1...done.

Loaded symbols for /lib/libsocket.so.1

Reading symbols from /lib/libc.so.1...done.

Loaded symbols for /lib/libc.so.1

Reading symbols from /opt/gcc/lib/libgcc_s.so.1...done.

Loaded symbols for /opt/gcc/lib/libgcc_s.so.1

Reading symbols from /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-

1.so.3...done.

Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.3

#0  0xec835356 in ?? ()

(gdb) bt

#0  0xec835356 in ?? ()

#1  0xfebc68ab in iconv () from /lib/libc.so.1

#2  0x080d9141 in php_iconv_string (in_p=0x8308488 "Hello, world.\n",
in_len=14, 

out=0x8047624, out_len=0x8047628, out_charset=0x830845c "UTF-8", 

in_charset=0x8309904 "UTF-8")

at /opt/sourceinstall/php-5.3.5/ext/iconv/iconv.c:501

#3  0x080dbb0c in php_if_iconv (ht=3, return_value=0x83084a0, 

return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 

/opt/sourceinstall/php-

5.3.5/ext/iconv/iconv.c:2327

#4  0x081caac5 in zend_do_fcall_common_helper_SPEC
(execute_data=0x83ec520) at 

zend_vm_execute.h:316

#5  0x081c9ec2 in execute (op_array=0x8308388) at zend_vm_execute.h:107

#6  0x081a1e3f in zend_eval_stringl (str=0x8047ce6 "echo
iconv(\"UTF-8\", \"UTF-

8\", \"Hello, world.\\n\");", str_len=0, retval_ptr=0x0,
string_name=0x82b9ec9 

"Command line code")

at /opt/sourceinstall/php-5.3.5/Zend/zend_execute_API.c:1193

#7  0x081a1fdb in zend_eval_stringl_ex (str=0x8047ce6 "echo
iconv(\"UTF-8\", 

\"UTF-8\", \"Hello, world.\\n\");", str_len=48, retval_ptr=0x0, 

string_name=0x82b9ec9 "Command line code", 

handle_exceptions=1) at /opt/sourceinstall/php-

5.3.5/Zend/zend_execute_API.c:1235

#8  0x081a2035 in zend_eval_string_ex (str=0x80475e0 "\016",
retval_ptr=0x0, 

string_name=0x82b9ec9 "Command line code", handle_exceptions=1)

at /opt/sourceinstall/php-5.3.5/Zend/zend_execute_API.c:1246

#9  0x08223584 in main (argc=3, argv=0x8047bf0) at
/opt/sourceinstall/php-

5.3.5/sapi/cli/php_cli.c:1282


[2011-02-09 11:34:09] johan...@php.net

I meant to write --disable-all, sorry for the mistake. Could you try



   ./configure --disable-all --with-i

Bug #53972 [Bgs]: Operator Type Casting Issue

[thipse_rahul at rediffmail dot com]

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

 ID: 53972
 User updated by:thipse_rahul at rediffmail dot com
 Reported by:thipse_rahul at rediffmail dot com
 Summary:Operator Type Casting Issue
 Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux/Windows
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

Thanks for reply johannes 



Yes I agree for float, 

Then Whey Case(2) & Case(3) gives wrong result.

Case 2:

$a = (int)((0.1+0.6) * 10); echo $a; // Act.Result: 7  // Exp. : 6

Case 3:

$a = (int)((0.1+0.8) * 10); echo $a; // Act.Result: 9  // Exp.: 8 



Hope you will give satisfactory feedback.



Thanks!


Previous Comments:

[2011-02-09 17:43:25] anon at anon dot anon

PHP guys, will you please stop giving people broken links?


[2011-02-09 14:18:33] johan...@php.net

Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
 
Thank you for your interest in PHP.

.


[2011-02-09 13:56:31] thipse_rahul at rediffmail dot com

Description:

Following code snippet -- 



Case 1:

$a = (int)((0.1+0.7) * 10); echo $a; // Result: 7 (Wrong) should give 8




Case 2:

$a = (int)((0.1+0.6) * 10); echo $a; // Result: 7

Case 3:

$a = (int)((0.1+0.8) * 10); echo $a; // Result: 9



Test script:
---
$a = (int)((0.1+0.7) * 10); 

echo $a;







Expected result:

8

Actual result:
--
7






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

Req #52052 [Asn]: add syslog support to FPM

[ef-lists at email dot de]

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

 ID: 52052
 User updated by:ef-lists at email dot de
 Reported by:ef-lists at email dot de
 Summary:add syslog support to FPM
 Status: Assigned
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   Linux/*NIX
 PHP Version:5.3SVN-2010-06-11 (SVN)
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

Oh you're right. We're actually experiencing this issue here.



At least the master process should always log to the configured
ident/facility - that's configuration and process manager
warnings/errors. By far the most important log output from FPM, IMHO.



I don't think this is a critical issue for FPM, as log output is never
discarded and other sapis (milter, thttpd, mod_php with Apache ErrorLog
set to syslog) do it the same way - although it would be nice to see
this resolved. I still wonder how to properly do this... open a separate
socket and mimic syslog behaviour? How to address this on Windows?



If you have updates, I'd be really curious. If I can help, let me know.
:-)


Previous Comments:

[2011-01-29 15:46:44] f...@php.net

thx for the up to date patch. But there is still a remaining problem:



php_syslog(), openlog() and closelog() can be called from FPM code, core
code, 

user script, module, sapi, ... 



If two calls to openlog() are made from two different places. Then this
is not 

sure than php_syslog() will log the right ident and facility.



This a global reflection to make around PHP and not only in FPM.



I'm working on it.


[2011-01-28 15:53:44] ef-lists at email dot de

Hi,



added a new patch, which can be applied to a vanilla PHP 5.3.5.



compiles and runs with:

--enable-debug without relevant warnings

--enable-maintainer-zts

without other flags

with having HAVE_SYSLOG_H in main/php_config.h undefined



changes:

* modified patch to work with FPM in 5.3.5

* added new parameters to config dump (todo: translate syslog prio and
facility to nice human-readable values)

* made comparing syslog facilities case-insensitive

* replaced syslog() calls with php_syslog()



Regards,

Edgar


[2011-01-12 16:15:58] ef-lists at email dot de

Hi Jerome,



are there any updates on this issue yet? With PHP 5.3.4 and PHP 5.3.5
the latest patch doesn't work anymore.



I'd be willing to port it to the latest release, if you're interested.
I'd still like to see this integrated into trunk and 5.3.X.



Regards,

Edgar


[2010-07-22 23:37:45] f...@php.net

some answers to your questions:



1- this is a bug. All comparaison should use strcasecmp so that users
can type 

facilities and log level with the case they want.



2- you're right. php_syslog() should be used instead of syslog()



4- after testing and validating, yes of course.



I need to take time reviewing all this. Thx again !


[2010-07-07 13:17:07] f...@php.net

Thanks for the reporting. I'll check that and answer you as soon as
possible.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=52052


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