[PHP-BUG] Bug #65844 [NEW]: array_search returns wrong last key if value it is 0

[marc-bennewitz at arcor dot de]

From: marc-bennewitz at arcor dot de
Operating system: linux
PHP version:  5.5.4
Package:  Arrays related
Bug Type: Bug
Bug description:array_search returns wrong last key if value it is 0

Description:

array_search returns wrong last key (instead of false) if value it is 0

Test script:
---
$arr = array(
  "ONE"=>1,
  "TWO"=>2,
  "THREE"=>3,
  "FOUR"=>4,
  "FIVE"=>5,
  "SIX"=>6,
  "SEVEN"=>7,
  "EIGHT"=>8,
  "NINE"=>9,
  "ZERO"=>0
);
var_dump(array_search('unknown', $arr));

Expected result:

bool(false)

Actual result:
--
string(4) "ZERO"

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

Bug #60778 [Com]: mysqli object crashes when given to var_dump

[marc at mittagqi dot com]

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

 ID: 60778
 Comment by: marc at mittagqi dot com
 Reported by:yoram dot b at zend dot com
 Summary:mysqli object crashes when given to var_dump
 Status: No Feedback
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux debian
 PHP Version:5.4.0RC5
 Assigned To:andrey
 Block user comment: N
 Private report: N

 New Comment:

addition to my previous comment: I experienced the bug as stated here:

 [2012-10-02 09:15 UTC] yoram dot b at zend dot com
The crash seems to be fixed.
the warning "Property access is not allowed yet" still exists. mysqlnd does not 
give such warning.


Previous Comments:

[2013-07-04 08:41:10] marc at mittagqi dot com

Just had this problem with PHP Version 5.4.16 on Linux infong 2.4 (1&1 managed 
server). Please reopen this bug.


[2013-02-18 00:35:37] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


[2012-10-02 09:19:09] and...@php.net

Will wait for your input. Thanks much!


[2012-10-02 09:15:35] yoram dot b at zend dot com

The crash seems to be fixed.
the warning "Property access is not allowed yet" still exists. mysqlnd does not 
give such warning.


[2012-10-02 08:57:17] yoram dot b at zend dot com

I will try that, but it will take time, since my default build is with mysqlnd, 
so I will have to build PHP specially for that.




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

https://bugs.php.net/bug.php?id=60778


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

Bug #60778 [Com]: mysqli object crashes when given to var_dump

[marc at mittagqi dot com]

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

 ID: 60778
 Comment by: marc at mittagqi dot com
 Reported by:yoram dot b at zend dot com
 Summary:mysqli object crashes when given to var_dump
 Status: No Feedback
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux debian
 PHP Version:5.4.0RC5
 Assigned To:andrey
 Block user comment: N
 Private report: N

 New Comment:

Just had this problem with PHP Version 5.4.16 on Linux infong 2.4 (1&1 managed 
server). Please reopen this bug.


Previous Comments:

[2013-02-18 00:35:37] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


[2012-10-02 09:19:09] and...@php.net

Will wait for your input. Thanks much!


[2012-10-02 09:15:35] yoram dot b at zend dot com

The crash seems to be fixed.
the warning "Property access is not allowed yet" still exists. mysqlnd does not 
give such warning.


[2012-10-02 08:57:17] yoram dot b at zend dot com

I will try that, but it will take time, since my default build is with mysqlnd, 
so I will have to build PHP specially for that.


[2012-09-25 13:40:00] and...@php.net

Can you try with recent 5.4 or 5.3 release and paste the result?
Thank you!




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

https://bugs.php.net/bug.php?id=60778


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

Bug #62171 [Com]: "Nesting level too deep - recursive dependency?" in case of ===

[marc-bennewitz at arcor dot de]

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

 ID: 62171
 Comment by: marc-bennewitz at arcor dot de
 Reported by:ray dot burgemeestre at gmail dot com
 Summary:"Nesting level too deep - recursive dependency?" in
 case of ===
 Status: Open
 Type:   Bug
 Package:*Programming Data Structures
 Operating System:   linux
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

I have the same issue in a logger method stringify all values into a readable 
format (Zend\Log\Formatter\Base::normalize) which ever fail if the value 
contains a self referencing entry. It's simply not possible to check this case 
so in will result in an infinite loop or we get the fatal here described.

AND on logging using the error handler there is a $context argument containing 
such a self reference :(


Previous Comments:

[2012-06-03 21:40:25] ray dot burgemeestre at gmail dot com

Didn't see your reply, that sounds good Felipe.., will check it out tomorrow.. 
thanks.


[2012-06-03 21:36:33] ray dot burgemeestre at gmail dot com

@carloschilazo of course removing the & fixes the error. You realize this is a 
bugreport right?
My point is that I think the === operator should still return true or false. In 
this case true as $a and $a[0] are the same object.
My testcase was a little ambiguous, shiranai7's version is better:  $a = 
array(); $a[0] = &$a;.


[2012-06-03 21:31:12] fel...@php.net

I've committed a change that will return immediately true the comparison 
between same array. So, at least your '$a = array(&$a); $a === $a;' will works.


[2012-06-03 20:54:27] carloschilazo at gmail dot com

I think the problem is your test script:



you are passing the value of $a by reference, and to invoke the value then it 
calls itself.

remove the & and it works


[2012-05-28 15:56:06] shiranai7 at hotmail dot com

I can confirm this on Windows. I also tried more cases:

For arrays: $a = array(); $a[0] = &$a;
For objects: $a = new stdClass; $a->b = &$a;

Results for comparisons of $a, $b

TypePHP OperatorResult
-
arrays  4.4.5   ==  fatal
arrays  4.4.5   === fatal
objects 4.4.5   ==  fatal
objects 4.4.5   === fatal

arrays  5.2.6   ==  fatal
arrays  5.2.6   === fatal
objects 5.2.6   ==  true
objects 5.2.6   === true

arrays  5.3.5   ==  fatal
arrays  5.3.5   === fatal
objects 5.3.5   ==  true
objects 5.3.5   === true

arrays  5.4.3   ==  fatal
arrays  5.4.3   === fatal
objects 5.4.3   ==  true
objects 5.4.3   === true


So this was fixed (either intentionally or along with general changes to object 
handling) in PHP 5 for objects but not for arrays.




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

https://bugs.php.net/bug.php?id=62171


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

Bug #64891 [Nab]: POST values in Google Chrome XHR.

[marc at kryn dot org]

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

 ID: 64891
 User updated by:marc at kryn dot org
 Reported by:marc at kryn dot org
 Summary:POST values in Google Chrome XHR.
 Status: Not a bug
 Type:   Bug
 Package:Built-in web server
 Operating System:   OS X 10.8.2
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

First of all: You've copy&pasted a not existing paragraph/mixed sentences
to a complete new paragraph. Your quote does not exist in that RFC!

The correct one is:

   Some HTTP/1.0 software has interpreted a Content-Type header without
   charset parameter incorrectly to mean "recipient should guess."
   Senders wishing to defeat this behavior MAY include a charset
   parameter even when the charset is ISO-8859-1 and SHOULD do so when
   it is known that it will not confuse the recipient.

   Unfortunately, some older HTTP/1.0 clients did not deal properly with
   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
   charset label provided by the sender; and those user agents that have
   a provision to "guess" a charset MUST use the charset from the
   content-type field if they support that charset, rather than the
   recipient's preference, when initially displaying a document. See
   section 3.7.1.

And here again: it says 'MAY' and 'SHOULD', and not 'MUST',
thus the charset is optional (MAY) and max recommended (SHOULD)
IF we know the charset. All as already mentioned in
   
   http://tools.ietf.org/html/rfc2616#section-3.7.

The only sentence with a MUST ...

 and those user agents that have
   a provision to "guess" a charset MUST use the charset from the
   content-type field if they support that charset, rather than the
   recipient's preference, when initially displaying a document.

... is not important here, since it's about the Response header.
We're talking about the opposite.


And here is what PHP should probably do:

http://tools.ietf.org/html/rfc2616#section-3.7.1

When no explicit charset
   parameter is provided by the sender, media subtypes of the "text"
   type are defined to have a default charset value of "ISO-8859-1" when
   received via HTTP.


I know now that other browsers add the Charset part to the Content-Type,
but that's however not important, since it's not a MUST regarding the RFC.
The PHP built-in web server should handle also requests without a charset
and assume that the text body of request without a defined charset is a
"ISO-8859-1".

The strange behaviour is that PHP _does_ parse the Request infrequently
correct, but mostly not.


Previous Comments:

[2013-05-21 22:59:47] google...@php.net

Well, first of all you're linking to the wrong part of the RFC when you're 
referring 
to the character encoding of the HTTP request header. There is undefined 
behavior 
according to the spec and you can see that here 
http://tools.ietf.org/html/rfc2616#section-3.4.1

where it clearly says:

   Some HTTP/1.0 software has interpreted a Content-Type header without
   charset parameter incorrectly to mean "recipient should guess."
   Senders wishing to defeat this behavior MAY include a charset
   parameter even when the charset is ISO-8859-1 and SHOULD do so when
   it is known that it will not confuse the recipient.

   Unfortunately, some older HTTP/1.0 clients did not deal properly with
   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
   charset label provided by the sender; and those user agents that have
   a provision to "guess" a charset MUST use the charset from the
   Content coding values indicate an encoding transformation that has
   been or can be applied to an entity. Content codings are primarily
   used to allow a document to be compressed or otherwise usefully
   transformed without losing the identity of its underlying media type
   and without loss of information. Frequently, the entity is stored in
   coded form, transmitted directly, and only decoded by the recipient.

So with that said if I go ahead and add the charset to the request header in 
your 
script I get the expected result.

';
var_dump($_POST);
exit;
}
?>



var xhr = new XMLHttpRequest();
xhr.open('POST', '<?= $_SERVER['SCRIPT_NAME'] ?>?test=1', true);
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded; 
charset=UTF-
8");
xhr.onload = function(){ document.getElementById('response').innerHTML = 
this.responseText; };
xhr.send("foo=bar");



You can see t

Bug #64891 [Nab]: POST values in Google Chrome XHR.

[marc at kryn dot org]

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

 ID: 64891
 User updated by:marc at kryn dot org
 Reported by:marc at kryn dot org
 Summary:POST values in Google Chrome XHR.
 Status: Not a bug
 Type:   Bug
 Package:Built-in web server
 Operating System:   OS X 10.8.2
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

Sorry, but you shouldn't modify the test script and then say 'it works with 
this 
modification'. I don't know what's the different in the header are to your 
example, but it's however not important, because mine produces a correct HTTP 
Request header.


Google Chrome sends with my script following header:

POST /test3.php?test=1 HTTP/1.1
Host: 127.0.0.1:8000
Connection: keep-alive
Content-Length: 7
Cache-Control: max-age=0
Origin: http://127.0.0.1:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.36 
(KHTML, like Gecko) 
Chrome/27.0.1453.93 Safari/537.36
Content-type: application/x-www-form-urlencoded
Accept: */*
Referer: http://127.0.0.1:8000/test3.php
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8

So it's a valid request header and should thus be handled correctly in PHP.
You've mentioned a missing Content-Length: it's not missing.
You've mentioned a missing charset in the Content-Type: This is not 
mandatory as you can read in http://tools.ietf.org/html/rfc2616#section-3.7.

Please re-open this ticket, since it's still a bug on php's side and not a 
support question.


Previous Comments:

[2013-05-21 22:15:42] google...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

This doesn't appear to be a bug in PHP. It looks to me like FireFox and some 
other UAs will modify the request headers resulting from that javascript code 
to 
comply with the spec.

Chrome seems to be sending a request, as a result of that javascript XHR, that 
is missing both the charset in the Content-type header as well as a Content-
length header. If I just let the UA do the encoding and formulate the request 
properly through javascript I get the expected result:

';
var_dump(file_get_contents("php://input"),$_POST,$_GET);
exit;
}
?>




 

var xhr = new XMLHttpRequest();
xhr.open('POST', '<?= $_SERVER['SCRIPT_NAME'] ?>?test=1', true);
xhr.onload = function(){ document.getElementById('response').innerHTML = 
this.responseText; };
var frm = new FormData(document.getElementById("myform"));
xhr.send(frm);


This works for me in all the latest versions of Chrome, FireFox, Opera, Safari, 
and IE.

Please feel free to reopen this bug report if you have additional evidence of a 
bug in PHP.


[2013-05-21 21:24:06] marc at kryn dot org

Description:

The PHP file servered through the built-int web server does not receive somehow 
the POST values from a AJAX/XHR POST call in Google Chrome. Only in Google 
Chrome.

Setup:

 - Create the file from the test script.
 - Open a built-in web server `php54 -S 127.0.0.1:8000 -t web/`
 - Open the file `http://127.0.0.1:8000/test.php`

This behaviour happens only for the built-in web server and Google Chrome. It 
works fine when running PHP behind fpm or as apache module. Any other browser 
works in all combinations (built-in server or not).

Tested on `5.4.15-1` installed through mac ports.

Test script:
---
';
var_dump($_POST);
exit;
}
?>



var xhr = new XMLHttpRequest();
xhr.open('POST', '<?= $_SERVER['SCRIPT_NAME'] ?>?test=1', true);
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
xhr.onload = function(){ document.getElementById('response').innerHTML = 
this.responseText; };
xhr.send('foo=bar');


Expected result:

received values:

array (size=1)
  'foo' => string 'bar' (length=3)


Actual result:
--
received values: 
array (size=0)
  empty






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

Bug #64814 [Opn]: Nano precision is not supported while decoding RFC 3339 formatted date/times.

[marc at weistroff dot net]

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

 ID: 64814
 User updated by:marc at weistroff dot net
 Reported by:marc at weistroff dot net
 Summary:Nano precision is not supported while decoding RFC
 3339 formatted date/times.
 Status: Open
 Type:   Bug
 Package:Date/time related
 PHP Version:5.5.0RC1
 Block user comment: N
 Private report: N

 New Comment:

I should have precise in the description of the bug that PHP returns an error 
when  
the number of digits in the "time-secfrac" part is > 8.


Previous Comments:

[2013-05-10 17:29:15] marc at weistroff dot net

Description:

While trying to parse a RFC3339 datetime, PHP will generate the error "The 
timezone could not be found in the database".

It can cause problems with other systems that produce such date/time strings.

As you can see on http://3v4l.org/Bl1Kv, it affects php from version 5.2.0 to 
5.5.0.

Test script:
---


Expected result:

array(15) {
  ["year"]=>
  int(2006)
  ["month"]=>
  int(12)
  ["day"]=>
  int(12)
  ["hour"]=>
  int(10)
  ["minute"]=>
  int(0)
  ["second"]=>
  int(0)
  ["fraction"]=>
  float(0.9)
  ["warning_count"]=>
  int(0)
  ["warnings"]=>
  array(0) {
  }
  ["error_count"]=>
  int(0)
  ["errors"]=>
  array(0) {
  }
  ["is_localtime"]=>
  bool(true)
  ["zone_type"]=>
  int(1)
  ["zone"]=>
  int(240)
  ["is_dst"]=>
  bool(false)
}

Actual result:
--
array(13) {
  ["year"]=>
  int(2006)
  ["month"]=>
  int(12)
  ["day"]=>
  int(12)
  ["hour"]=>
  int(10)
  ["minute"]=>
  int(0)
  ["second"]=>
  int(0)
  ["fraction"]=>
  float(0.)
  ["warning_count"]=>
  int(0)
  ["warnings"]=>
  array(0) {
  }
  ["error_count"]=>
  int(1)
  ["errors"]=>
  array(1) {
[0]=>
string(47) "The timezone could not be found in the database"
  }
  ["is_localtime"]=>
  bool(true)
  ["zone_type"]=>
  int(0)
}






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

[PHP-BUG] Bug #64814 [NEW]: Nano precision is not supported while decoding RFC 3339 formatted date/times.

[marc at weistroff dot net]

From: marc at weistroff dot net
Operating system: 
PHP version:  5.5.0RC1
Package:  Date/time related
Bug Type: Bug
Bug description:Nano precision is not supported while decoding RFC 3339 
formatted date/times.

Description:

While trying to parse a RFC3339 datetime, PHP will generate the error "The

timezone could not be found in the database".

It can cause problems with other systems that produce such date/time
strings.

As you can see on http://3v4l.org/Bl1Kv, it affects php from version 5.2.0
to 
5.5.0.

Test script:
---


Expected result:

array(15) {
  ["year"]=>
  int(2006)
  ["month"]=>
  int(12)
  ["day"]=>
  int(12)
  ["hour"]=>
  int(10)
  ["minute"]=>
  int(0)
  ["second"]=>
  int(0)
  ["fraction"]=>
  float(0.9)
  ["warning_count"]=>
  int(0)
  ["warnings"]=>
  array(0) {
  }
  ["error_count"]=>
  int(0)
  ["errors"]=>
  array(0) {
  }
  ["is_localtime"]=>
  bool(true)
  ["zone_type"]=>
  int(1)
  ["zone"]=>
  int(240)
  ["is_dst"]=>
  bool(false)
}

Actual result:
--
array(13) {
  ["year"]=>
  int(2006)
  ["month"]=>
  int(12)
  ["day"]=>
  int(12)
  ["hour"]=>
  int(10)
  ["minute"]=>
  int(0)
  ["second"]=>
  int(0)
  ["fraction"]=>
  float(0.)
  ["warning_count"]=>
  int(0)
  ["warnings"]=>
  array(0) {
  }
  ["error_count"]=>
  int(1)
  ["errors"]=>
  array(1) {
[0]=>
string(47) "The timezone could not be found in the database"
  }
  ["is_localtime"]=>
  bool(true)
  ["zone_type"]=>
  int(0)
}

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

[PHP-BUG] Bug #64459 [NEW]: Wrong value on casting a float point number into int

[marc-bennewitz at arcor dot de]

From: marc-bennewitz at arcor dot de
Operating system: Linux acer-aspire-5680 3.2.0-38-
PHP version:  master-Git-2013-03-19 (Git)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Wrong value on casting a float point number into int

Description:

On some circumstances it's possible to get a wrong integer value on casting
from float.

I can reproduce this bug with the following installations:
php -v
PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013
14:34:31) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

./sapi/cli/php -v
PHP 5.6.0-dev (cli) (built: Mar 17 2013 22:02:54) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.6.0-dev, Copyright (c) 1998-2013 Zend Technologies

Test script:
---
// this works
$v = (float) 6;
var_dump($v, (int)$v);

// this is wrong
$v = log(64, 2);
var_dump($v, (int)$v);

Expected result:

float(6)
int(6)
float(6)
int(6)


Actual result:
--
float(6)
int(6)
float(6)
int(5)


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

Bug #62632 [Fbk->Opn]: Incorrect image generated

[marc at phpmyadmin dot net]

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

 ID: 62632
 User updated by:marc at phpmyadmin dot net
 Reported by:marc at phpmyadmin dot net
 Summary:Incorrect image generated
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:GD related
 Operating System:   Linux
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

The solution is to use null as the second parameter of ImageJPEG(). In PHP 
5.3.13, using '' worked.


Previous Comments:

[2013-02-18 13:00:44] ka...@php.net

have you tried to call the script like:



And see if PHP errors out? If headers are sent its often hidden by browsers. 
Simply go to image.php directly and see if you either get a lot of 'binary' 
text or an actual PHP error.


[2012-09-15 05:27:35] david at nnucomputerwhiz dot com

Works for me in php 5.4.4-4 from Debian testing.

----
[2012-07-22 20:52:10] marc at phpmyadmin dot net

Here is the image I used:
http://www.infomarc.info/MarcDelisle-140x185.jpg


[2012-07-22 19:18:32] a...@php.net

$contents = file_get_contents('marc.jpg');

A link to marc.jpg would be useful.

----
[2012-07-22 15:17:53] marc at phpmyadmin dot net

Description:

The test script (master.html calling image.php) works fine with PHP 5.3.13 but 
fails to produce an image with PHP 5.4.4 or 5.4.5.

'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-libdir=lib64' 
'--disable-debug' '--enable-calendar' '--with-gd=shared' '--with-freetype-dir' 
'--with-mysql=shared,mysqlnd' '--with-mysqli=shared,mysqlnd' '--with-regex=php' 
'--with-png-dir=/usr/lib' '--with-zlib=shared' '--with-iconv=shared' 
'--enable-ftp' '--with-mcrypt=shared' '--with-bz2=shared' '--enable-zip' 
'--with-jpeg-dir=/usr/lib' '--enable-mbstring' '--without-sqlite' 
'--enable-dom' '--enable-json' '--with-pdo-mysql=mysqlnd' '--with-pear' 
'--enable-bcmath' '--with-curl=shared' '--with-ldap=shared,/usr' 
'--with-gettext=shared' '--with-snmp=shared' '--enable-soap' '--enable-sockets' 

Test script:
---
master.html:







image.php:



Expected result:

A photo is displayed.

Actual result:
--
The alt tag of the photo is displayed.






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

Bug #54955 [Com]: FastCGI doesn't recognize Windows relative paths

[marc dot fauser+php at gmail dot com]

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

 ID: 54955
 Comment by: marc dot fauser+php at gmail dot com
 Reported by:johanntrg at msn dot com
 Summary:FastCGI doesn't recognize Windows relative paths
 Status: Open
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Windows 7 64bits SP1
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

I have the same problem since months. I would even pay money to get this bug 
fixed. So far you can "solve" it by using mklink.

e.g.
mklink /J files ..\files


Previous Comments:

[2011-05-30 22:08:30] johanntrg at msn dot com

Description:

I have configured my webserver (nginx) to have its document root out of its 
working path in "..\files" (please, note the two dots). When I request static 
files, it serves them without any problem. Anyway If I request a PHP file, the 
request it's not served because php-cgi.exe running as the fastCGI server al 
127.0.0.1:9000 returns an error 400 code.

If I user absolute paths it works. Also, if I move the "..\files" folder to 
"./files" (please, note the only one dot) and I change the document root to 
reflect that new relative path.

So It looks that relative paths with two dots are not getting resolved by php-
cgi.exe as fastCGI server.







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

Req #60716 [Com]: Ability to set PDO connection timeout in milliseconds

[marc-bennewitz at arcor dot de]

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

 ID: 60716
 Comment by: marc-bennewitz at arcor dot de
 Reported by:markrose at markrose dot ca
 Summary:Ability to set PDO connection timeout in
 milliseconds
 Status: Open
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   n/a
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

I would like it because 1second can be a long time if you would like to connect 
to a failover server you have minimum of 2x1 seconds.

Sure if it's not possible with libmysql it's a MySQL-BUG only but for mysqlnd 
(and other db driver) it could be done.

The simplest way would be to allow a float value as timeout and if the driver 
supports it use it else round it up to the next second.


Previous Comments:

[2012-05-02 07:32:47] u...@php.net

For the MySQL part this can be considered Bogus/Not a bug because PHP is the 
wrong place to ask for it. Please, file a bug at MySQL.

The underlying MySQL C API does not offer sub second granularity for setting 
the connect timeout. If it was to be fixed, it should be done at the lowest 
level which is the MySQL C API. No matter whether we are talking mysqlnd or 
MySQL Client Library (libmysql). See also 
http://dev.mysql.com/doc/refman/5.6/en/mysql-options.html and 
http://blog.ulf-wendel.de/?p=273

For the PDO part, I am not too keen of driver specific settings. What's the 
purpose of PDO if not providing an abstraction for it... However, for years now 
PDO seems kind of neglected, nobody feeling too much responsible for it.


[2012-01-11 17:20:38] markrose at markrose dot ca

Description:

I'd like the ability to set PDO's connection timeout (to MySQL specifically) in 
milliseconds. The lowest the timeout can current be set to is 1 second, which 
is 
an extremely long time to wait for a database machine to reply.

I run a synchronously replicated MySQL environment (Galera), and I'd like to be 
able to move on to the next machine if the database doesn't respond in say, 10 
ms. Instead, PHP waits one second. This reduces the throughput of my PHP 
scripts 
from several hundred per second to only a handful per second, severely 
impacting 
performance and quickly exhausting the PHP thread pool, leading to timeouts.







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

Bug #62632 [Opn]: Incorrect image generated

[marc at phpmyadmin dot net]

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

 ID: 62632
 User updated by:marc at phpmyadmin dot net
 Reported by:marc at phpmyadmin dot net
 Summary:Incorrect image generated
 Status: Open
 Type:   Bug
 Package:GD related
 Operating System:   Linux
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Here is the image I used:
http://www.infomarc.info/MarcDelisle-140x185.jpg


Previous Comments:

[2012-07-22 19:18:32] a...@php.net

$contents = file_get_contents('marc.jpg');

A link to marc.jpg would be useful.


[2012-07-22 15:17:53] marc at phpmyadmin dot net

Description:

The test script (master.html calling image.php) works fine with PHP 5.3.13 but 
fails to produce an image with PHP 5.4.4 or 5.4.5.

'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-libdir=lib64' 
'--disable-debug' '--enable-calendar' '--with-gd=shared' '--with-freetype-dir' 
'--with-mysql=shared,mysqlnd' '--with-mysqli=shared,mysqlnd' '--with-regex=php' 
'--with-png-dir=/usr/lib' '--with-zlib=shared' '--with-iconv=shared' 
'--enable-ftp' '--with-mcrypt=shared' '--with-bz2=shared' '--enable-zip' 
'--with-jpeg-dir=/usr/lib' '--enable-mbstring' '--without-sqlite' 
'--enable-dom' '--enable-json' '--with-pdo-mysql=mysqlnd' '--with-pear' 
'--enable-bcmath' '--with-curl=shared' '--with-ldap=shared,/usr' 
'--with-gettext=shared' '--with-snmp=shared' '--enable-soap' '--enable-sockets' 

Test script:
---
master.html:







image.php:



Expected result:

A photo is displayed.

Actual result:
--
The alt tag of the photo is displayed.






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

[PHP-BUG] Bug #62632 [NEW]: Incorrect image generated

[marc at phpmyadmin dot net]

From: marc at phpmyadmin dot net
Operating system: Linux
PHP version:  5.4.5
Package:  GD related
Bug Type: Bug
Bug description:Incorrect image generated

Description:

The test script (master.html calling image.php) works fine with PHP 5.3.13
but fails to produce an image with PHP 5.4.4 or 5.4.5.

'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs'
'--with-libdir=lib64' '--disable-debug' '--enable-calendar'
'--with-gd=shared' '--with-freetype-dir' '--with-mysql=shared,mysqlnd'
'--with-mysqli=shared,mysqlnd' '--with-regex=php' '--with-png-dir=/usr/lib'
'--with-zlib=shared' '--with-iconv=shared' '--enable-ftp'
'--with-mcrypt=shared' '--with-bz2=shared' '--enable-zip'
'--with-jpeg-dir=/usr/lib' '--enable-mbstring' '--without-sqlite'
'--enable-dom' '--enable-json' '--with-pdo-mysql=mysqlnd' '--with-pear'
'--enable-bcmath' '--with-curl=shared' '--with-ldap=shared,/usr'
'--with-gettext=shared' '--with-snmp=shared' '--enable-soap'
'--enable-sockets' 

Test script:
---
master.html:







image.php:



Expected result:

A photo is displayed.

Actual result:
--
The alt tag of the photo is displayed.

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

[PHP-BUG] Bug #62492 [NEW]: dba_firstkey & dba_nextkey retuns NULL (instead false) on invalid dba resource

[marc-bennewitz at arcor dot de]

From: marc-bennewitz at arcor dot de
Operating system: openSUSE 11.3 (x86_64)
PHP version:  5.4.4
Package:  DBM/DBA related
Bug Type: Bug
Bug description:dba_firstkey & dba_nextkey retuns NULL (instead false) on 
invalid dba resource

Description:

The functions "dba_firstkey" & "dba_nextkey" retuns NULL (instead of false)
on invalid dba resource.
It's documented as "Returns the key on success or FALSE on failure."
That can result in an infinite loop on iterate over items.

Test script:
---
$dba = false;

var_dump(dba_firstkey($dba));
var_dump(dba_nextkey($dba));

Expected result:

PHP Warning:  dba_firstkey() expects parameter 1 to be resource, boolean
given in /tmp/dba_firstkey_nextkey.php on line 5

Warning: dba_firstkey() expects parameter 1 to be resource, boolean given
in /tmp/dba_firstkey_nextkey.php on line 5
boolean(false)
PHP Warning:  dba_nextkey() expects parameter 1 to be resource, boolean
given in /tmp/dba_firstkey_nextkey.php on line 6

Warning: dba_nextkey() expects parameter 1 to be resource, boolean given in
/tmp/dba_firstkey_nextkey.php on line 6
boolean(false)

Actual result:
--
PHP Warning:  dba_firstkey() expects parameter 1 to be resource, boolean
given in /tmp/dba_firstkey_nextkey.php on line 5

Warning: dba_firstkey() expects parameter 1 to be resource, boolean given
in /tmp/dba_firstkey_nextkey.php on line 5
NULL
PHP Warning:  dba_nextkey() expects parameter 1 to be resource, boolean
given in /tmp/dba_firstkey_nextkey.php on line 6

Warning: dba_nextkey() expects parameter 1 to be resource, boolean given in
/tmp/dba_firstkey_nextkey.php on line 6
NULL

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

[PHP-BUG] Bug #62491 [NEW]: Iterating over items + dba_delete not working

[marc-bennewitz at arcor dot de]

From: marc-bennewitz at arcor dot de
Operating system: openSUSE 11.3 (x86_64)
PHP version:  5.4.4
Package:  DBM/DBA related
Bug Type: Bug
Bug description:Iterating over items + dba_delete not working

Description:

With some handlers it's not possible to iterate over items if there will be
items deleted within iteration.

Test script:
---
// Script to delete items with specific prefix

$dba = dba_open(sys_get_temp_dir() . DIRECTORY_SEPARATOR .
uniqid('zfcache_dba_'), 'c', 'qdbm');

dba_insert('key1', 'value', $dba);
dba_insert('test2', 'value', $dba);
dba_insert('key3', 'value', $dba);
dba_insert('test4', 'value', $dba);
dba_insert('key5', 'value', $dba);

$key = dba_firstkey($dba);
var_dump($key);
while ($key !== false) {
$key = dba_nextkey($dba);
var_dump($key);
}

echo '#' . PHP_EOL;

$key = dba_firstkey($dba);
while ($key !== false) {
if (substr($key, 0, 3) === 'key') {
var_dump($key);
dba_delete($key, $dba);
}
$key = dba_nextkey($dba);
}

echo '#' . PHP_EOL;

$key = dba_firstkey($dba);
var_dump($key);
while ($key !== false) {
$key = dba_nextkey($dba);
var_dump($key);
}


Expected result:

string(4) "key1"
string(5) "test2"
string(4) "key3"
string(5) "test4"
string(4) "key5"
bool(false)
#
string(4) "key1"
string(4) "key3"
string(4) "key5"
#
string(5) "test2"
string(5) "test4"
bool(false)

Actual result:
--
flatfile -> correct
inifile  -> wrong (breaks iteration after first delete)
gdbm -> wrong (breaks iteration after first delete)
qdbm -> correct
db4  -> correct

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

[PHP-BUG] Bug #62490 [NEW]: dba_delete returns true on missing item (inifile)

[marc-bennewitz at arcor dot de]

From: marc-bennewitz at arcor dot de
Operating system: openSUSE 11.3 (x86_64)
PHP version:  5.4.4
Package:  DBM/DBA related
Bug Type: Bug
Bug description:dba_delete returns true on missing item (inifile)

Description:

The function "dba_delete" returns true on delete a non-existing item using
inifile handler.

I tested flatfile, inifile, gdbm, qdbm and db4. All other hander not
tested.

Test script:
---
$dba = dba_open(sys_get_temp_dir() . DIRECTORY_SEPARATOR . uniqid('dba_'),
'c', 'inifile');

var_dump(dba_delete('unknown', $dba));

Expected result:

bool(false)

Actual result:
--
bool(true)

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

[PHP-BUG] Bug #62489 [NEW]: dba_insert not working as expected

[marc-bennewitz at arcor dot de]

From: marc-bennewitz at arcor dot de
Operating system: openSUSE 11.3 (x86_64)
PHP version:  5.4.4
Package:  DBM/DBA related
Bug Type: Bug
Bug description:dba_insert not working as expected

Description:

The function "dba_insert" doesn't work as expected with most handlers.
On calling "dba_insert" on an already existing key the function should
return false and do not trigger a warning but that's not the case on most
tested handlers.

Test script:
---
$dba = dba_open(sys_get_temp_dir() . DIRECTORY_SEPARATOR . uniqid('dba_'),
'c', 'qdbm');

var_dump(dba_insert('key', 'test1', $dba));
var_dump(dba_insert('key', 'test2', $dba));
var_dump(dba_fetch('key', $dba));

Expected result:

bool(true)
bool(false)
string(5) "test1"

Actual result:
--
   RETURN1  RETURN2  WRANING
flatfile   true falseYES
inifiletrue true NO
gdbm   true falseYES
qdbm   true falseYES
db4true falseNO
-> Didn't test not listed handlers !

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

[PHP-BUG] Bug #62345 [NEW]: Misspelling of Occurred

[marc at easen dot co dot uk]

From: marc at easen dot co dot uk
Operating system: All
PHP version:  Irrelevant
Package:  Unknown/Other Function
Bug Type: Bug
Bug description:Misspelling of Occurred

Description:

There are quite a few occurrences where the word 'occurred' is spelt
incorrect

https://github.com/php/php-src/pull/104/files


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

Bug #61523 [Nab]: First call to fgets in SplFileObject doesn't increase file pointer position

[marc at lamarciana dot com]

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

 ID: 61523
 User updated by:marc at lamarciana dot com
 Reported by:marc at lamarciana dot com
 Summary:First call to fgets in SplFileObject doesn't
 increase file pointer position
 Status: Not a bug
 Type:   Bug
 Package:SPL related
 Operating System:   Debian squeeze
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Ok, I see, thank you.

I think my confusion arose because fgets() reads next line from the file, but 
when no line has been read, fgets then reads current line, which is line 0. If 
when no line has been read we should consider we are somehow before line 0, 
then calling key() before reading any line maybe should return something 
different than 0, maybe -1 or false.


Previous Comments:

[2012-03-28 13:07:37] cataphr...@php.net

This seems correct. The first line is line 0, not 1. The error is that you're 
calling key() before the first line is read. You should do it after (or just 
use a foreach loop).


[2012-03-27 07:54:26] marc at lamarciana dot com

Description:

Calling key() method in a new SplFileObject gives 0. This is the expected 
result.

If you call now fgets() method and again key() method it gives again 0 as a 
result. I think this is not the expected behavior.

Subsequent calls to fgets() followed by key() method increases the result by 1 
(1, 2, 3...). This is again the expected result.

The behavior is the same with SplFileObject::READ_AHEAD flag.

More information:

http://stackoverflow.com/questions/9876999/first-call-to-fgets-in-splfileobject-doesnt-advance-file-key

Consider following text file, test.txt for the Test Script:
1
2
3

Test script:
---
key());
$line = $file->fgets();
var_dump($file->key());
$line = $file->fgets();
var_dump($file->key());
$line = $file->fgets();
var_dump($file->key());

Expected result:

int(0) int(1) int(2) int(3)

Actual result:
--
int(0) int(0) int(1) int(2)






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

[PHP-BUG] Bug #61523 [NEW]: First call to fgets in SplFileObject doesn't increase file pointer position

[marc at lamarciana dot com]

From: 
Operating system: Debian squeeze
PHP version:  5.3.10
Package:  SPL related
Bug Type: Bug
Bug description:First call to fgets in SplFileObject doesn't increase file 
pointer position

Description:

Calling key() method in a new SplFileObject gives 0. This is the expected
result.

If you call now fgets() method and again key() method it gives again 0 as a
result. I think this is not the expected behavior.

Subsequent calls to fgets() followed by key() method increases the result
by 1 (1, 2, 3...). This is again the expected result.

The behavior is the same with SplFileObject::READ_AHEAD flag.

More information:

http://stackoverflow.com/questions/9876999/first-call-to-fgets-in-splfileobject-doesnt-advance-file-key

Consider following text file, test.txt for the Test Script:
1
2
3

Test script:
---
key());
$line = $file->fgets();
var_dump($file->key());
$line = $file->fgets();
var_dump($file->key());
$line = $file->fgets();
var_dump($file->key());

Expected result:

int(0) int(1) int(2) int(3)

Actual result:
--
int(0) int(0) int(1) int(2)

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

[PHP-BUG] Bug #61033 [NEW]: __FUNCTION__ doesn't report correctly in alias trait methods

[marc at easen dot co dot uk]

From: 
Operating system: Gentoo
PHP version:  5.4.0RC7
Package:  Reflection related
Bug Type: Bug
Bug description:__FUNCTION__ doesn't report correctly in alias trait methods

Description:

The __FUNCTION__ magic constant does not report correctly in aliased
methods 
within traits.


When a trait function is called by it's initial name __FUNCTION__ is
correct. 
When it is called by it aliased name __FUNCTION__ still reports as the
initial 
name, but debug_backtrace() reports the aliased method name.

Test script:
---
foo();
echo PHP_EOL;
echo 'bar()' . PHP_EOL;
$instance->bar();


Expected result:

foo()
__FUNCTION__ = foo
$backtrace[0]['function']) = foo

bar()
__FUNCTION__ = bar
$backtrace[0]['function']) = bar


Actual result:
--
foo()
__FUNCTION__ = foo
$backtrace[0]['function']) = foo

bar()
__FUNCTION__ = foo
$backtrace[0]['function']) = bar


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

Req #60889 [Wfx]: make array keys changeable

[marc-bennewitz at arcor dot de]

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

 ID: 60889
 User updated by:marc-bennewitz at arcor dot de
 Reported by:marc-bennewitz at arcor dot de
 Summary:make array keys changeable
 Status: Wont fix
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

You missed out that your simple example puts the changed key at the end of the 
array. That means if you need to preserve the order you have to copy the 
complete array and that's slow on large arrays.


Previous Comments:

[2012-01-26 00:25:09] johan...@php.net

Your requested function can be written like this:

function array_change_key(&$arr, $old, $new) {
if (isset($arr[$new]) {
trigger_error(...);
}
$arr[$new] = $arr[$old];
unset($arr[$old]);
}

This creates neither a copy of the array nor of the element ... due to copy on 
rite. And it's exactly hat we would do internally.

PHP already has many array funtions and we won't add new ones which can be 
implemented easily in userland.


[2012-01-26 00:06:08] marc-bennewitz at arcor dot de

Description:

On working with maps it's often needed to change the key of an existing element 
of an array, but it's currently not possible without a copy of the array or a 
unset + new element.

Test script:
---
// function to change the key
$arr = array('a' => 'a');
array_change_key($arr, 'a', 'b');
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (warning existing key)
$arr = array('a' => 'a', 'b' => 'b');
array_change_key($arr, 'a', 'b');
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (overwrite existing element)
$arr = array('a' => 'a', 'b' => 'b');
array_change_key($arr, 'a', 'b', true);
var_dump($arr);


echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (leave existing element)
$arr = array('a' => 'a', 'b' => 'b');
array_change_key($arr, 'a', 'b', false);
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// foreach key as ref
$arr = array('a' => 'a', 'b' => 'b');
foreach ($arr as &$k => $v) {
$k = 'b';
}


Expected result:

array(1) {
  ["b"]=>
  string(1) "a"
}
###
Warning: Can't change the array key 'a' to an already existing key 'b'
array(2) {
  ["a"]=>
  string(1) "a",
  ["b"]=>
  string(1) "b"
}
###
array(1) {
  ["b"]=>
  string(1) "a"
}
###
array(1) {
  ["b"]=>
  string(1) "b"
}
###
Warning: Can't change the array key 'a' to an already existing key 'b'
array(2) {
  ["a"]=>
  string(1) "a",
  ["b"]=>
  string(1) "b"
}

Actual result:
--
Function related:
There is no funcation to change an array key

foreach related:
PHP Fatal error:  Key element cannot be a reference






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

[PHP-BUG] Req #60889 [NEW]: make array keys changeable

[marc-bennewitz at arcor dot de]

From: 
Operating system: 
PHP version:  Irrelevant
Package:  Arrays related
Bug Type: Feature/Change Request
Bug description:make array keys changeable

Description:

On working with maps it's often needed to change the key of an existing
element of an array, but it's currently not possible without a copy of the
array or a unset + new element.

Test script:
---
// function to change the key
$arr = array('a' => 'a');
array_change_key($arr, 'a', 'b');
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (warning existing key)
$arr = array('a' => 'a', 'b' => 'b');
array_change_key($arr, 'a', 'b');
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (overwrite existing element)
$arr = array('a' => 'a', 'b' => 'b');
array_change_key($arr, 'a', 'b', true);
var_dump($arr);


echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (leave existing element)
$arr = array('a' => 'a', 'b' => 'b');
array_change_key($arr, 'a', 'b', false);
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// foreach key as ref
$arr = array('a' => 'a', 'b' => 'b');
foreach ($arr as &$k => $v) {
$k = 'b';
}


Expected result:

array(1) {
  ["b"]=>
  string(1) "a"
}
###
Warning: Can't change the array key 'a' to an already existing key 'b'
array(2) {
  ["a"]=>
  string(1) "a",
  ["b"]=>
  string(1) "b"
}
###
array(1) {
  ["b"]=>
  string(1) "a"
}
###
array(1) {
  ["b"]=>
  string(1) "b"
}
###
Warning: Can't change the array key 'a' to an already existing key 'b'
array(2) {
  ["a"]=>
  string(1) "a",
  ["b"]=>
  string(1) "b"
}

Actual result:
--
Function related:
There is no funcation to change an array key

foreach related:
PHP Fatal error:  Key element cannot be a reference

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

Bug #52975 [Com]: VC10 Builds Wanted

[marc at misterphp dot com]

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

 ID: 52975
 Comment by: marc at misterphp dot com
 Reported by:xiaomao5 at live dot com
 Summary:VC10 Builds Wanted
 Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Windows
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

+1 vor vc10


Previous Comments:

[2010-10-02 22:30:59] paj...@php.net

Next PHP major release should be compiler independent or almost independent.

As of now it is VC9 the standard. Remember that VC10 has been released this 
year while 5.3 has been released in June 2009.

But no bug or feature request, already part of the roadmap > bogus.


[2010-10-02 22:18:20] xiaomao5 at live dot com

Description:

I have Visual Studio 2010 and Windows SDK for Windows 7 and .NET 4. When I am 
compiling Windows extensions for PHP. PHP's VC9 build doesn't work with it. I 
have to compile the whole PHP. but I want to publish them to help other people 
that don't have compilers. If I publish the whole php vc10 build myself. Other 
people will afraid i add virus in it. Can PHP release official vc10 build??







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

[PHP-BUG] Bug #55778 [NEW]: PHPIniDir only works correctly for forward slashes, not backward slashes

[marc at leftek dot com]

From: 
Operating system: Windows 7
PHP version:  5.3.8
Package:  Windows Installer
Bug Type: Bug
Bug description:PHPIniDir only works correctly for forward slashes, not 
backward slashes

Description:

I think it was the installer that put the line in my httpd.conf:
PHPIniDir "C:\Program Files (x86)\PHP\"

This resulted in phpinfo() producing:
Configuration File (php.ini) Path   C:\Windows
Loaded Configuration File   (none)

This causes the INI not to be found and PHP just uses defaults. Changing
the 
slashes in the above line to:
PHPIniDir "C:/Program Files (x86)/PHP/"

and phpinfo() correctly produces:
Configuration File (php.ini) Path   C:\Windows
Loaded Configuration File   C:\Program Files (x86)\PHP\php.ini

Hopefully this can get changed to accept either kind of slash since Windows

Installer seems to use the wrong one.  Also it would be helpful to have
apache 
output an error log if no php.ini was found in the expected location and it
was 
switching to defaults.


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

Req #50029 [Com]: Weird invoke issue on class as property

[marc dot gray at gmail dot com]

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

 ID: 50029
 Comment by: marc dot gray at gmail dot com
 Reported by:marc dot gray at gmail dot com
 Summary:Weird invoke issue on class as property
 Status: Analyzed
 Type:   Feature/Change Request
 Package:Class/Object related
 Operating System:   Ubuntu 9.04
 PHP Version:5.3.0
 Block user comment: N
 Private report: N

 New Comment:

I've been thinking about this since the same issue appears to exist with 
assigning a closure to a static 
variable too (tested in 5.3.5, 5.3.8 & 5.4alpha3.

//--
// Create a very basic static class
class closureProperty {
static public $myClosure;
}

// Assign a closure to a class property
closureProperty::$myClosure = function() { echo('Hi'); };

// Fatal error: Function name must be a string
closureProperty::$myClosure();

// Works as expected
$safeCopy = closureProperty::$myClosure;
$safeCopy();
//--

I can understand why it happens with dynamic properties, apparently you can 
have a variable and function named 
identically? I admit I've never tried.

I would propose making identically named variables and functions as deprecated 
(does anyone who's any good 
actually do that? Talk about poor readability...) and implement a collision 
warning in the mean time. I would 
also suggest this makes less sense in a static case (due to $ variable prefix) 
than it did in a dynamic case, 
and should be changed.

If nothing else, some discussion on the matter would be lovely.

Thoughts?


Previous Comments:

[2011-02-07 22:36:54] dhaarbrink at gmail dot com

@bkarwin: The control would be passed to __call(), since there is no way to 
disambiguate. __call() would then be responsible for deciding what to do.

I have to agree with Matthew, it's a huge WTF. It just doesn't work as it 
should (that's beyond what is expected).


[2010-04-07 20:22:38] bkar...@php.net

How would Matthew's suggestion work if a magic __call() method is present?

class b {
  private $x;

  public function __call($method, $args) { echo "Called\n"; }

  function __construct() { 
$this->x = new a(); 
$this->x(); 
  } 

}

Should this execute $this->__call("x") and output "Called" or should it execute 
$this->x->__invoke() and output "Invoked"?


[2010-04-07 14:52:19] ballouc at gmail dot com

I'm in agreement with the Matt's last suggestion.  I believe that errors should 
only be raised in the event of a collision.  The current implementation of the 
__invoke method, IMO, would not perform as a third party developer would have 
anticipated.  My personal choice would be to throw an E_WARNING for collisions 
as I have seen ~E_NOTICE far too often.  

Personally, I believe that an __invoke collision occurring would be more 
indicative of a developer error than intentional.  If this is not the case, and 
you find many people readily anticipate having both foo() and __invoke called 
in succession, this would need to be discussed further as that is also a viable 
option.


[2010-04-07 13:41:14] weierophin...@php.net

I can understand wanting to ensure that collisions between existing methods and 
invokable properties don't occur, but when there aren't any collisions, it 
doesn't make sense.

I'd argue that the following behavior should be implemented:
* If no matching method exists, simply allow invoking.
* If a matching method exists, call the method, and raise either an E_NOTICE or 
E_WARNING indicating the collision.

Right now, it's a fairly big WTF moment -- you expect it to work, and instead 
get an E_FATAL. Copying to a temporary variable is code clutter, particularly 
when you know the object is invokable.


[2009-11-02 15:58:23] ka...@php.net

There was lots of discussion about this, because it could override class 
methods like:

class Test { 
  private $closure;

  public function __construct() {
$this->closure = function() {
  echo 'Hello World';
};
  }

  public function closure() {
echo 'Hello PHP';
  }

  public function call() {
$this->closure();
  }
}

$test = new Test;

// Call Test::$closure or Test::closure() now?
$test->call();


What you need to do is to copy the instance into a variable like:
$closoure = $this->closure;
$closure();




The remainder 

Bug #52376 [Com]: opendir() cannot open UNC paths in IIS7 using passthrough auth.

[marc dot seitz at ww-informatik dot de]

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

 ID: 52376
 Comment by: marc dot seitz at ww-informatik dot de
 Reported by:ryan at kisc dot edu dot np
 Summary:opendir() cannot open UNC paths in IIS7 using
 passthrough auth.
 Status: Assigned
 Type:   Bug
 Package:*Directory/Filesystem functions
 Operating System:   win64 - W2008R2
 PHP Version:5.3.2
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Hi Guys,

we have exactly the same problem now.
We want to migrate to Windows Server 2008 R2 with IIS 7.5, FastCGI, PHP 5.3.6.

When I try to do a file_get_contents() or opendir() I 
always will get the error:
Warning: fopen(): failed to open stream: Permission denied in 
D:\inetpub\wwwroot\XXX.php on line 26

The Application-Pools of the IIS are running under a Domain-Account which has 
access to the Network Share.

I don't know how to solve this problem.

Any ideas of you?

Thanks 
Marc


Previous Comments:

[2011-01-13 04:24:50] mark at internode dot on dot net

Hi I am having the same problem with PHP 5.3.5 running under IIS 7.5, FastCGI, 
Windows Server 2008 R2 where I am simply trying to access a file on another 
server using a UNC path.

$uploadfile = "\.txt";
$fh = fopen($uploadfile, 'r') or die("Can't open file $uploadfile");

I have tried granting "everyone" full permissions for the share and the file 
system but it still does not work.

This code works perfectly if the file is stored on the same server and is 
accessed through a local path.

Other things I have tried inlcude:
- setting the defaultappool to use a specific user and granting that user 
permissions on the share and file system
- using "network" as above

Any other ideas on this one?


[2010-07-20 04:42:43] ahar...@php.net

(Restoring status.)

As a fellow Chrome user, I feel your pain. :)


[2010-07-20 04:08:58] ryan at kisc dot edu dot np

sorry about the line breaks, apparently this site doesn't like what Chrome does 
when I resize the text box. I'll be more careful in the future. Actually this 
site seems to hate Chrome altogether. 
I keep getting "incorrect username" constantly. The bug site is buggy, at least 
in Chrome.


[2010-07-20 04:04:31] ryan at kisc dot edu dot np

Well, that allows me to browse to the folder via chrome and essentially does 
the 
same thing as the 
workaround from #50542 but only on the one folder which could work. What it 
does 
not appear to do 
is give me programmatic access to the folder. The instructions in that KB are 
outdated as it uses 
adsutil.vbs and the setting is the same as the "Physical Path Credentials" from 
the IIS manager. 
This could work, in a much less than ideal way, if there is some way to run 
"opendir" on the 
virtual directory without specifying the unc path (since the UNC path itself 
still does not work). 
I could just be unaware of how, since it seems to use the system paths and not 
honor or even 
acknowledge virtual directories. I tried lots of different formats against my 
better judgement but 
none worked. I even tried using the http path reference. Still no joy. I've 
used 
PHP since 1998 but 
realize something could have changed at any one of the releases, however I'm 
not 
sure I see how a 
virtual directory could solve the ability to use opendir. Fair enough if this 
was just a try. I'm 
happy to keep trying if it can help the community. This worked fabulously in 
IIS6. I also confess 
that it appears to be Microsoft's fault. Very frustrating.

I wonder if I can create a symbolic link equivalent. I've done this before in 
older versions of 
windows, but I don't think I've ever done it to a network share. In my case I 
may be able to just 
move the share to the IIS server and be done with it, but I'm willing to stick 
this out if it will 
help find a solution to this issue.


[2010-07-19 23:50:21] paj...@php.net

Can you try to follow the advice here please:

http://support.microsoft.com/kb/214806




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

https://bugs.php.net/bug.php?id=52376


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

Req #53100 [Com]: Add function to list available vars

[marc-bennewitz at arcor dot de]

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

 ID: 53100
 Comment by: marc-bennewitz at arcor dot de
 Reported by:marc-bennewitz at arcor dot de
 Summary:Add function to list available vars
 Status: Open
 Type:   Feature/Change Request
 Package:Semaphore related
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

what is the state of this issue ?
The patch exists for 9 month !


Previous Comments:

[2010-10-27 23:12:45] marc-bennewitz at arcor dot de

patch:
- added function shm_get_vars(resource $id) to get an associative array of all 
variable keys and values
- added function shm_list_vars(resource $id) to get an indexed array of all keys


[2010-10-18 21:53:58] marc-bennewitz at arcor dot de

Description:

It's not possible to get a list of available vars.

Test script:
---
shm_put_var($shm, 123, 'one');
ahm_put_var($shm, 456, 'two');
var_dump(shm_list_vars($shm));

Expected result:

array(2) {
  [0]=>
  int(123)
  [1]=>
  int(456)
}
*or*
array(2) {
  [123]=>
  string(3)"one"
  [456]=>
  string(3)"two"
}

Actual result:
--
PHP Fatal error:  Call to undefined function shm_list_vars() in ...






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

Req #53173 [Com]: shm_stat to get total & free

[marc-bennewitz at arcor dot de]

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

 ID: 53173
 Comment by: marc-bennewitz at arcor dot de
 Reported by:marc-bennewitz at arcor dot de
 Summary:shm_stat to get total & free
 Status: Open
 Type:   Feature/Change Request
 Package:Semaphore related
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

what is the state of this issue ?
The patch exists for 9 month !


Previous Comments:

[2010-10-26 21:18:55] marc-bennewitz at arcor dot de

Description:

Adding function to get total size of memory and to get free size of memory of 
the opened shm segment.

Test script:
---
>From test script:

// test errors
var_dump(shm_stat());
var_dump(shm_stat(1));
var_dump(shm_stat(""));

// open shm segment
$key = ftok(dirname(__FILE__)."/008.phpt", 't');
$shmId = shm_attach($key, 1024);
var_dump($shmId);

// first stat call
var_dump(shm_stat($shmId));

// write data + stat
var_dump(shm_put_var($shmId, 10, '10'));
var_dump(shm_put_var($shmId, 20, '20'));
var_dump(shm_put_var($shmId, 30, '30'));
var_dump(shm_stat($shmId));

// remove data + stat
var_dump(shm_remove_var($shmId, 20));
var_dump(shm_stat($shmId));

// re-open shm segment with different size + stat
var_dump(shm_detach($shmId));
$shmId = shm_attach($key, 10240);
var_dump($shmId);
var_dump(shm_stat($shmId));

// remove shm segment + stat
var_dump(shm_remove($shmId));
var_dump(shm_stat($shmId));

echo "Done\n";

Expected result:

Warning: shm_stat() expects exactly 1 parameter, 0 given in %s on line %d
bool(false)

Warning: shm_stat() expects parameter 1 to be resource, integer given in %s on 
line %d
bool(false)

Warning: shm_stat() expects parameter 1 to be resource, string given in %s on 
line %d
bool(false)
resource(%d) of type (sysvshm)
array(2) {
  ["total"]=>
  int(1024)
  ["free"]=>
  int(%d)
}
bool(true)
bool(true)
bool(true)
array(2) {
  ["total"]=>
  int(1024)
  ["free"]=>
  int(%d)
}
bool(true)
array(2) {
  ["total"]=>
  int(1024)
  ["free"]=>
  int(%d)
}
bool(true)
resource(%d) of type (sysvshm)
array(2) {
  ["total"]=>
  int(1024)
  ["free"]=>
  int(%d)
}
bool(true)
array(2) {
  ["total"]=>
  int(1024)
  ["free"]=>
  int(%d)
}
Done







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

Bug #55227 [Fbk->Csd]: php.exe is not executable

[marc dot frost at ecg-leipzig dot de]

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

 ID: 55227
 User updated by:marc dot frost at ecg-leipzig dot de
 Reported by:marc dot frost at ecg-leipzig dot de
 Summary:php.exe is not executable
-Status: Feedback
+Status: Closed
 Type:   Bug
 Package:*Compile Issues
 Operating System:   WinXP 32bit
 PHP Version:5.4.0alpha2
 Block user comment: N
 Private report: N

 New Comment:

it works with 313379


Previous Comments:

[2011-07-18 08:00:42] paj...@php.net

Please try a snapshot again, be sure to wait for the revision 313379 or higher.


[2011-07-18 07:34:52] marc dot frost at ecg-leipzig dot de

sorry no additional errors, i got the version from the qa page, unziped and 
tried to start


[2011-07-18 07:27:30] paj...@php.net

You certainly got additional errors, please write them down here.


[2011-07-18 07:05:56] marc dot frost at ecg-leipzig dot de

Description:

alpha2 is not executable
alpha1 work correct

Expected result:

C:\Programme\Zend\php-5.4.0alpha2-Win32-VC9-x86>php.exe -v
Das angegebene Programm kann nicht ausgeführt werden.

C:\Programme\Zend\php-5.4.0alpha2-Win32-VC9-x86>php-cgi.exe -v
Das angegebene Programm kann nicht ausgeführt werden.

C:\Programme\Zend\php-5.4.0alpha2-Win32-VC9-x86>php-win.exe -v
Das angegebene Programm kann nicht ausgeführt werden.








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

Bug #55227 [Fbk->Opn]: php.exe is not executable

[marc dot frost at ecg-leipzig dot de]

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

 ID: 55227
 User updated by:marc dot frost at ecg-leipzig dot de
 Reported by:marc dot frost at ecg-leipzig dot de
 Summary:php.exe is not executable
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:*Compile Issues
 Operating System:   WinXP 32bit
 PHP Version:5.4.0alpha2
 Block user comment: N
 Private report: N

 New Comment:

sorry no additional errors, i got the version from the qa page, unziped and 
tried to start


Previous Comments:

[2011-07-18 07:27:30] paj...@php.net

You certainly got additional errors, please write them down here.


[2011-07-18 07:05:56] marc dot frost at ecg-leipzig dot de

Description:

alpha2 is not executable
alpha1 work correct

Expected result:

C:\Programme\Zend\php-5.4.0alpha2-Win32-VC9-x86>php.exe -v
Das angegebene Programm kann nicht ausgeführt werden.

C:\Programme\Zend\php-5.4.0alpha2-Win32-VC9-x86>php-cgi.exe -v
Das angegebene Programm kann nicht ausgeführt werden.

C:\Programme\Zend\php-5.4.0alpha2-Win32-VC9-x86>php-win.exe -v
Das angegebene Programm kann nicht ausgeführt werden.








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

[PHP-BUG] Bug #55227 [NEW]: php.exe is not executable

[marc dot frost at ecg-leipzig dot de]

From: 
Operating system: WinXP 32bit
PHP version:  5.4.0alpha2
Package:  *Compile Issues
Bug Type: Bug
Bug description:php.exe is not executable

Description:

alpha2 is not executable
alpha1 work correct

Expected result:

C:\Programme\Zend\php-5.4.0alpha2-Win32-VC9-x86>php.exe -v
Das angegebene Programm kann nicht ausgeführt werden.

C:\Programme\Zend\php-5.4.0alpha2-Win32-VC9-x86>php-cgi.exe -v
Das angegebene Programm kann nicht ausgeführt werden.

C:\Programme\Zend\php-5.4.0alpha2-Win32-VC9-x86>php-win.exe -v
Das angegebene Programm kann nicht ausgeführt werden.



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

Bug #54950 [Com]: simplexml_load_[string|file]: error_get_last is useless

[marc-bennewitz at arcor dot de]

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

 ID: 54950
 Comment by: marc-bennewitz at arcor dot de
 Reported by:marc-bennewitz at arcor dot de
 Summary:simplexml_load_[string|file]: error_get_last is
 useless
 Status: Open
 Type:   Bug
 Package:SimpleXML related
 Operating System:   Linux
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

OK 'libxml_use_internal_errors' can also be used

but the last reported error is unhelpful anyhow


Previous Comments:

[2011-05-29 18:07:26] marc-bennewitz at arcor dot de

Description:

On loading an invalid xml catched errors using error_get_last aren't
helpful because the message is nearly empty "simplexml_load_string():   
 ^"



It looks like there are more errors reported and the last error is the
most unhelpful error but this is the only good catchable error (see
example).



A workaround only exists using an own error handler but it's nasty :(

Test script:
---
$xml = <<



test



XML;



echo 'LOAD INVALID XML STRING' . PHP_EOL;

$simpleXML = simplexml_load_string($xml);



echo 'DETECTED ERROR:' . PHP_EOL;

if ($simpleXML === false) {

$err = error_get_last();

var_dump($err);

}

Expected result:

LOAD INVALID XML STRING

PHP Warning:  simplexml_load_string(): Entity: line 4: parser error :
Opening and ending tag mismatch: config line 2 and other in
/tmp/bug_simpleXmlLoad.php on line 11



Warning: simplexml_load_string(): Entity: line 4: parser error : Opening
and ending tag mismatch: config line 2 and other in
/tmp/bug_simpleXmlLoad.php on line 11

DETECTED ERROR:

array(4) {

  ["type"]=>

  int(2)

  ["message"]=>

  string(34) "simplexml_load_string(): Entity: line 4: parser error :
Opening and ending tag mismatch: config line 2 and other"

  ["file"]=>

  string(26) "/tmp/bug_simpleXmlLoad.php"

  ["line"]=>

  int(11)

}

Actual result:
--
LOAD INVALID XML STRING

PHP Warning:  simplexml_load_string(): Entity: line 4: parser error :
Opening and ending tag mismatch: config line 2 and other in
/tmp/bug_simpleXmlLoad.php on line 11



Warning: simplexml_load_string(): Entity: line 4: parser error : Opening
and ending tag mismatch: config line 2 and other in
/tmp/bug_simpleXmlLoad.php on line 11

PHP Warning:  simplexml_load_string():  in
/tmp/bug_simpleXmlLoad.php on line 11



Warning: simplexml_load_string():  in /tmp/bug_simpleXmlLoad.php
on line 11

PHP Warning:  simplexml_load_string(): ^ in
/tmp/bug_simpleXmlLoad.php on line 11



Warning: simplexml_load_string(): ^ in
/tmp/bug_simpleXmlLoad.php on line 11

DETECTED ERROR:

array(4) {

  ["type"]=>

  int(2)

  ["message"]=>

  string(34) "simplexml_load_string(): ^"

  ["file"]=>

  string(26) "/tmp/bug_simpleXmlLoad.php"

  ["line"]=>

  int(11)

}






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

[PHP-BUG] Bug #54950 [NEW]: simplexml_load_[string|file]: error_get_last is useless

[marc-bennewitz at arcor dot de]

From: 
Operating system: Linux
PHP version:  5.3.6
Package:  SimpleXML related
Bug Type: Bug
Bug description:simplexml_load_[string|file]: error_get_last is useless

Description:

On loading an invalid xml catched errors using error_get_last aren't
helpful because the message is nearly empty "simplexml_load_string():  
  ^"



It looks like there are more errors reported and the last error is the most
unhelpful error but this is the only good catchable error (see example).



A workaround only exists using an own error handler but it's nasty :(

Test script:
---
$xml = <<



test



XML;



echo 'LOAD INVALID XML STRING' . PHP_EOL;

$simpleXML = simplexml_load_string($xml);



echo 'DETECTED ERROR:' . PHP_EOL;

if ($simpleXML === false) {

$err = error_get_last();

var_dump($err);

}

Expected result:

LOAD INVALID XML STRING

PHP Warning:  simplexml_load_string(): Entity: line 4: parser error :
Opening and ending tag mismatch: config line 2 and other in
/tmp/bug_simpleXmlLoad.php on line 11



Warning: simplexml_load_string(): Entity: line 4: parser error : Opening
and ending tag mismatch: config line 2 and other in
/tmp/bug_simpleXmlLoad.php on line 11

DETECTED ERROR:

array(4) {

  ["type"]=>

  int(2)

  ["message"]=>

  string(34) "simplexml_load_string(): Entity: line 4: parser error :
Opening and ending tag mismatch: config line 2 and other"

  ["file"]=>

  string(26) "/tmp/bug_simpleXmlLoad.php"

  ["line"]=>

  int(11)

}

Actual result:
--
LOAD INVALID XML STRING

PHP Warning:  simplexml_load_string(): Entity: line 4: parser error :
Opening and ending tag mismatch: config line 2 and other in
/tmp/bug_simpleXmlLoad.php on line 11



Warning: simplexml_load_string(): Entity: line 4: parser error : Opening
and ending tag mismatch: config line 2 and other in
/tmp/bug_simpleXmlLoad.php on line 11

PHP Warning:  simplexml_load_string():  in
/tmp/bug_simpleXmlLoad.php on line 11



Warning: simplexml_load_string():  in /tmp/bug_simpleXmlLoad.php on
line 11

PHP Warning:  simplexml_load_string(): ^ in
/tmp/bug_simpleXmlLoad.php on line 11



Warning: simplexml_load_string(): ^ in /tmp/bug_simpleXmlLoad.php
on line 11

DETECTED ERROR:

array(4) {

  ["type"]=>

  int(2)

  ["message"]=>

  string(34) "simplexml_load_string(): ^"

  ["file"]=>

  string(26) "/tmp/bug_simpleXmlLoad.php"

  ["line"]=>

  int(11)

}

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

Bug #54242 [Csd]: dba_insert returns true if key already exists

[marc-bennewitz at arcor dot de]

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

 ID: 54242
 User updated by:marc-bennewitz at arcor dot de
 Reported by:marc-bennewitz at arcor dot de
 Summary:dba_insert returns true if key already exists
 Status: Closed
 Type:   Bug
 Package:DBM/DBA related
 Operating System:   Linux
 PHP Version:5.3.5
 Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

Much thanks for the very fast fix !



But on a little bit more tests I found similar problems with the
'inifile' handler -> returns true on second insert without a warning



PS: not tested the other handlers yet.


Previous Comments:

[2011-03-13 15:23:24] fel...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

The bug has been fixed in trunk, I'll merge it in 5.3 branch when the
5.3.6 got released.



Thanks.


[2011-03-13 15:21:59] fel...@php.net

Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=309172
Log: - Fixed bug #54242 (dba_insert returns true if key already exists)

----
[2011-03-13 15:11:36] marc-bennewitz at arcor dot de

Description:

dba_insert returns true if key already exists using handler 'flatfile'

Test script:
---
$path = __DIR__ . '/test.dba';

$mode = 'c';

$handler = 'flatfile';



@unlink($path);

$dba = dba_open($path, $mode, $handler);



// first insert success

var_dump(dba_insert('key', 'value', $dba));



// second insert failed -> already exists

var_dump(dba_insert('key', 'value', $dba));

Expected result:

bool(true)

PHP Warning:  dba_insert(key): Key already exists in
/mnt/workspace/zf2/cache/tests/test_dba.php on line 15



Warning: dba_insert(key): Key already exists in
/mnt/workspace/zf2/cache/tests/test_dba.php on line 15

bool(false)

Actual result:
--
bool(true)

PHP Warning:  dba_insert(key): Key already exists in
/mnt/workspace/zf2/cache/tests/test_dba.php on line 15



Warning: dba_insert(key): Key already exists in
/mnt/workspace/zf2/cache/tests/test_dba.php on line 15

bool(true)






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

[PHP-BUG] Bug #54242 [NEW]: dba_insert returns true if key already exists

[marc-bennewitz at arcor dot de]

From: 
Operating system: Linux
PHP version:  5.3.5
Package:  DBM/DBA related
Bug Type: Bug
Bug description:dba_insert returns true if key already exists

Description:

dba_insert returns true if key already exists using handler 'flatfile'

Test script:
---
$path = __DIR__ . '/test.dba';

$mode = 'c';

$handler = 'flatfile';



@unlink($path);

$dba = dba_open($path, $mode, $handler);



// first insert success

var_dump(dba_insert('key', 'value', $dba));



// second insert failed -> already exists

var_dump(dba_insert('key', 'value', $dba));

Expected result:

bool(true)

PHP Warning:  dba_insert(key): Key already exists in
/mnt/workspace/zf2/cache/tests/test_dba.php on line 15



Warning: dba_insert(key): Key already exists in
/mnt/workspace/zf2/cache/tests/test_dba.php on line 15

bool(false)

Actual result:
--
bool(true)

PHP Warning:  dba_insert(key): Key already exists in
/mnt/workspace/zf2/cache/tests/test_dba.php on line 15



Warning: dba_insert(key): Key already exists in
/mnt/workspace/zf2/cache/tests/test_dba.php on line 15

bool(true)

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

Bug #53651 [Asn->Csd]: Under mysqlnd, mysqli_affected_rows() returns 0

[marc at phpmyadmin dot net]

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

 ID: 53651
 User updated by:marc at phpmyadmin dot net
 Reported by:marc at phpmyadmin dot net
 Summary:Under mysqlnd, mysqli_affected_rows() returns 0
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux
 PHP Version:5.3.4
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

Sorry for the disturbance.


Previous Comments:

[2011-01-05 13:34:49] u...@php.net

No, neither adding PDO nor the moon phase can impact it.


[2011-01-05 12:28:57] marc at phpmyadmin dot net

Andrey,

I had a permission problem at MySQL level that produced the "0" output.
Now I can no longer reproduce the problem with the test script, but I
still have this problem in phpMyAdmin. I'll try to come up with a new
test script.


[2011-01-05 12:08:52] and...@php.net

Can you post output from the script with freshly created table and
freshly inserted row. Please, run the script twice. Thanks!


[2011-01-05 12:00:16] marc at phpmyadmin dot net

Hi Andrey,

here is my configuration, maybe the presence of PDO has an impact?



./configure --with-apxs2=/usr/local/apache2/bin/apxs \

--with-libdir=lib64 \

--disable-debug \

--enable-calendar \

--with-gd=shared \

--with-freetype-dir \

--with-mysql=shared,mysqlnd \

--with-mysqli=shared,mysqlnd \

--with-regex=php \

--with-png-dir=/usr/lib \

--with-zlib=shared \

--with-iconv=shared \

--enable-ftp \

--with-mcrypt=shared \

--with-bz2=shared \

--enable-zip \

--with-jpeg-dir=/usr/lib \

--enable-mbstring \

--without-sqlite \

--enable-dom \

--enable-json \

--enable-pdo=shared \

--with-pdo-mysql=shared,mysqlnd \

--without-pdo-sqlite \

--with-pear \

--enable-spl \

--enable-bcmath \

--with-curl=shared \

--with-ldap=shared,/usr \

--with-gettext=shared \

--with-snmp=shared \

--enable-sockets


[2011-01-05 10:31:08] and...@php.net

I can't reproduce it. Maybe it's bogus due to something else. Here are
my results :



myslqnd + MySQL 5.5.8 (executed twice in a row)



and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 1

and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 0



myslqnd + MySQL 5.1-dev (executed twice in a row)

and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 1

and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 0



As you see, the second time the result is 0. Why? It is a feature or
gotcha of MySQL. If the row doesn't change affected_rows is 0. And the
row doesn't change from toto to toto there is no change, thus the row is
left intact.




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


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

Bug #53651 [Fbk->Asn]: Under mysqlnd, mysqli_affected_rows() returns 0

[marc at phpmyadmin dot net]

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

 ID: 53651
 User updated by:marc at phpmyadmin dot net
 Reported by:marc at phpmyadmin dot net
 Summary:Under mysqlnd, mysqli_affected_rows() returns 0
-Status: Feedback
+Status: Assigned
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux
 PHP Version:5.3.4
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

Andrey,

I had a permission problem at MySQL level that produced the "0" output.
Now I can no longer reproduce the problem with the test script, but I
still have this problem in phpMyAdmin. I'll try to come up with a new
test script.


Previous Comments:

[2011-01-05 12:08:52] and...@php.net

Can you post output from the script with freshly created table and
freshly inserted row. Please, run the script twice. Thanks!


[2011-01-05 12:00:16] marc at phpmyadmin dot net

Hi Andrey,

here is my configuration, maybe the presence of PDO has an impact?



./configure --with-apxs2=/usr/local/apache2/bin/apxs \

--with-libdir=lib64 \

--disable-debug \

--enable-calendar \

--with-gd=shared \

--with-freetype-dir \

--with-mysql=shared,mysqlnd \

--with-mysqli=shared,mysqlnd \

--with-regex=php \

--with-png-dir=/usr/lib \

--with-zlib=shared \

--with-iconv=shared \

--enable-ftp \

--with-mcrypt=shared \

--with-bz2=shared \

--enable-zip \

--with-jpeg-dir=/usr/lib \

--enable-mbstring \

--without-sqlite \

--enable-dom \

--enable-json \

--enable-pdo=shared \

--with-pdo-mysql=shared,mysqlnd \

--without-pdo-sqlite \

--with-pear \

--enable-spl \

--enable-bcmath \

--with-curl=shared \

--with-ldap=shared,/usr \

--with-gettext=shared \

--with-snmp=shared \

--enable-sockets


[2011-01-05 10:31:08] and...@php.net

I can't reproduce it. Maybe it's bogus due to something else. Here are
my results :



myslqnd + MySQL 5.5.8 (executed twice in a row)



and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 1

and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 0



myslqnd + MySQL 5.1-dev (executed twice in a row)

and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 1

and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 0



As you see, the second time the result is 0. Why? It is a feature or
gotcha of MySQL. If the row doesn't change affected_rows is 0. And the
row doesn't change from toto to toto there is no change, thus the row is
left intact.


[2011-01-04 19:08:06] marc at phpmyadmin dot net

Description:

In PHP 5.3.4 (also 5.3.3 and 5.3.2), connecting to MySQL 5.1.49 with
mysqli extension under mysqlnd, I always obtain 0 as the result of
mysqli_affected_rows() following an UPDATE that changed one row.



Works fine under PHP 5.2.14 + MySQL 5.1.49 client library.



Thanks,

Marc Delisle

Test script:
---


Expected result:

Affected rows (UPDATE): 1

Actual result:
--
Affected rows (UPDATE): 0






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

Bug #53651 [Fbk->Asn]: Under mysqlnd, mysqli_affected_rows() returns 0

[marc at phpmyadmin dot net]

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

 ID: 53651
 User updated by:marc at phpmyadmin dot net
 Reported by:marc at phpmyadmin dot net
 Summary:Under mysqlnd, mysqli_affected_rows() returns 0
-Status: Feedback
+Status: Assigned
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux
 PHP Version:5.3.4
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

Hi Andrey,

here is my configuration, maybe the presence of PDO has an impact?



./configure --with-apxs2=/usr/local/apache2/bin/apxs \

--with-libdir=lib64 \

--disable-debug \

--enable-calendar \

--with-gd=shared \

--with-freetype-dir \

--with-mysql=shared,mysqlnd \

--with-mysqli=shared,mysqlnd \

--with-regex=php \

--with-png-dir=/usr/lib \

--with-zlib=shared \

--with-iconv=shared \

--enable-ftp \

--with-mcrypt=shared \

--with-bz2=shared \

--enable-zip \

--with-jpeg-dir=/usr/lib \

--enable-mbstring \

--without-sqlite \

--enable-dom \

--enable-json \

--enable-pdo=shared \

--with-pdo-mysql=shared,mysqlnd \

--without-pdo-sqlite \

--with-pear \

--enable-spl \

--enable-bcmath \

--with-curl=shared \

--with-ldap=shared,/usr \

--with-gettext=shared \

--with-snmp=shared \

--enable-sockets


Previous Comments:

[2011-01-05 10:31:08] and...@php.net

I can't reproduce it. Maybe it's bogus due to something else. Here are
my results :



myslqnd + MySQL 5.5.8 (executed twice in a row)



and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 1

and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 0



myslqnd + MySQL 5.1-dev (executed twice in a row)

and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 1

and...@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php b.php

Affected rows (UPDATE): 0



As you see, the second time the result is 0. Why? It is a feature or
gotcha of MySQL. If the row doesn't change affected_rows is 0. And the
row doesn't change from toto to toto there is no change, thus the row is
left intact.

----
[2011-01-04 19:08:06] marc at phpmyadmin dot net

Description:

In PHP 5.3.4 (also 5.3.3 and 5.3.2), connecting to MySQL 5.1.49 with
mysqli extension under mysqlnd, I always obtain 0 as the result of
mysqli_affected_rows() following an UPDATE that changed one row.



Works fine under PHP 5.2.14 + MySQL 5.1.49 client library.



Thanks,

Marc Delisle

Test script:
---


Expected result:

Affected rows (UPDATE): 1

Actual result:
--
Affected rows (UPDATE): 0






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

[PHP-BUG] Req #53653 [NEW]: Allow reading message even with server http code > 400

[marc dot vachette at gmail dot com]

From: 
Operating system: window
PHP version:  5.2.16
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:Allow reading message even with server http code > 400

Description:

When the server i connect through SoapClient returns an error, ir returns
it whith 

http code 500, and somme error message.



The problem is that php_soap extension do not show message content if the
error 

code is larger than 400.






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

[PHP-BUG] Bug #53651 [NEW]: Under mysqlnd, mysqli_affected_rows() returns 0

[marc at phpmyadmin dot net]

From: 
Operating system: Linux
PHP version:  5.3.4
Package:  MySQLi related
Bug Type: Bug
Bug description:Under mysqlnd, mysqli_affected_rows() returns 0

Description:

In PHP 5.3.4 (also 5.3.3 and 5.3.2), connecting to MySQL 5.1.49 with mysqli
extension under mysqlnd, I always obtain 0 as the result of
mysqli_affected_rows() following an UPDATE that changed one row.



Works fine under PHP 5.2.14 + MySQL 5.1.49 client library.



Thanks,

Marc Delisle

Test script:
---


Expected result:

Affected rows (UPDATE): 1

Actual result:
--
Affected rows (UPDATE): 0

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

Req #52555 [Com]: Headers_List not returning HTTP Status Code

[marc-bennewitz at arcor dot de]

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

 ID: 52555
 Comment by: marc-bennewitz at arcor dot de
 Reported by:dragoo...@php.net
 Summary:Headers_List not returning HTTP Status Code
 Status: Closed
 Type:   Feature/Change Request
 Package:*Web Server problem
 PHP Version:5.3.3
 Assigned To:dragoonis
 Block user comment: N
 Private report: N

 New Comment:

Why it's not committed to a branch ?

When it will be available ?


Previous Comments:

[2010-12-11 14:47:55] paj...@php.net

It is committed in trunk (svn trunk).


[2010-12-11 13:37:05] marc-bennewitz at arcor dot de

Hi,



I can't find the function "http_response_code" within 5.3.4 and no
documentation about it or a message on changelog of 5.3.4.



What does it mean "Committed to 5.3.99" ?

How many years we have to wait :/



It would be very helpful to have some publish time/version.



Greetings,

Marc


[2010-08-09 15:11:17] ka...@php.net

Committed to 5.3.99


[2010-08-09 15:10:34] ka...@php.net

Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=302033
Log: Implemented FR #52555 (Ability to get HTTP response code)
 - Patch by Paul Dragoonis


[2010-08-09 00:49:31] dragoo...@php.net

The following patch has been added/updated:

Patch Name: http_response_code
Revision:   1281307771
URL:   
http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281307771




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


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

Req #52555 [Com]: Headers_List not returning HTTP Status Code

[marc-bennewitz at arcor dot de]

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

 ID: 52555
 Comment by: marc-bennewitz at arcor dot de
 Reported by:dragoo...@php.net
 Summary:Headers_List not returning HTTP Status Code
 Status: Closed
 Type:   Feature/Change Request
 Package:*Web Server problem
 PHP Version:5.3.3
 Assigned To:dragoonis
 Block user comment: N
 Private report: N

 New Comment:

Hi,



I can't find the function "http_response_code" within 5.3.4 and no
documentation about it or a message on changelog of 5.3.4.



What does it mean "Committed to 5.3.99" ?

How many years we have to wait :/



It would be very helpful to have some publish time/version.



Greetings,

Marc


Previous Comments:

[2010-08-09 15:11:17] ka...@php.net

Committed to 5.3.99


[2010-08-09 15:10:34] ka...@php.net

Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=302033
Log: Implemented FR #52555 (Ability to get HTTP response code)
 - Patch by Paul Dragoonis


[2010-08-09 00:49:31] dragoo...@php.net

The following patch has been added/updated:

Patch Name: http_response_code
Revision:   1281307771
URL:   
http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281307771


[2010-08-09 00:48:57] dragoo...@php.net

The following patch has been added/updated:

Patch Name: httpd_response_code
Revision:   1281307736
URL:   
http://bugs.php.net/patch-display.php?bug=52555&patch=httpd_response_code&revision=1281307736


[2010-08-07 15:54:44] dragoo...@php.net

After some discussions in IRC we have concluded that it's best to make a
new function to give us the current response code rather than modifying
existing functionality.



I've added the patch below to be tested and committed into TRUNK or
wherever.



Cheers.

Paul.




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


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

Req #53100 [Com]: Add function to list available vars

[marc-bennewitz at arcor dot de]

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

 ID: 53100
 Comment by: marc-bennewitz at arcor dot de
 Reported by:marc-bennewitz at arcor dot de
 Summary:Add function to list available vars
 Status: Open
 Type:   Feature/Change Request
 Package:Semaphore related
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

patch:

- added function shm_get_vars(resource $id) to get an associative array
of all variable keys and values

- added function shm_list_vars(resource $id) to get an indexed array of
all keys


Previous Comments:

[2010-10-18 21:53:58] marc-bennewitz at arcor dot de

Description:

It's not possible to get a list of available vars.

Test script:
---
shm_put_var($shm, 123, 'one');

ahm_put_var($shm, 456, 'two');

var_dump(shm_list_vars($shm));

Expected result:

array(2) {

  [0]=>

  int(123)

  [1]=>

  int(456)

}

*or*

array(2) {

  [123]=>

  string(3)"one"

  [456]=>

  string(3)"two"

}

Actual result:
--
PHP Fatal error:  Call to undefined function shm_list_vars() in ...






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

[PHP-BUG] Req #53173 [NEW]: shm_stat to get total & free

[marc-bennewitz at arcor dot de]

From: 
Operating system: Linux
PHP version:  Irrelevant
Package:  Semaphore related
Bug Type: Feature/Change Request
Bug description:shm_stat to get total & free

Description:

Adding function to get total size of memory and to get free size of memory
of the opened shm segment.

Test script:
---
>From test script:



// test errors

var_dump(shm_stat());

var_dump(shm_stat(1));

var_dump(shm_stat(""));



// open shm segment

$key = ftok(dirname(__FILE__)."/008.phpt", 't');

$shmId = shm_attach($key, 1024);

var_dump($shmId);



// first stat call

var_dump(shm_stat($shmId));



// write data + stat

var_dump(shm_put_var($shmId, 10, '10'));

var_dump(shm_put_var($shmId, 20, '20'));

var_dump(shm_put_var($shmId, 30, '30'));

var_dump(shm_stat($shmId));



// remove data + stat

var_dump(shm_remove_var($shmId, 20));

var_dump(shm_stat($shmId));



// re-open shm segment with different size + stat

var_dump(shm_detach($shmId));

$shmId = shm_attach($key, 10240);

var_dump($shmId);

var_dump(shm_stat($shmId));



// remove shm segment + stat

var_dump(shm_remove($shmId));

var_dump(shm_stat($shmId));



echo "Done\n";

Expected result:

Warning: shm_stat() expects exactly 1 parameter, 0 given in %s on line %d

bool(false)



Warning: shm_stat() expects parameter 1 to be resource, integer given in %s
on line %d

bool(false)



Warning: shm_stat() expects parameter 1 to be resource, string given in %s
on line %d

bool(false)

resource(%d) of type (sysvshm)

array(2) {

  ["total"]=>

  int(1024)

  ["free"]=>

  int(%d)

}

bool(true)

bool(true)

bool(true)

array(2) {

  ["total"]=>

  int(1024)

  ["free"]=>

  int(%d)

}

bool(true)

array(2) {

  ["total"]=>

  int(1024)

  ["free"]=>

  int(%d)

}

bool(true)

resource(%d) of type (sysvshm)

array(2) {

  ["total"]=>

  int(1024)

  ["free"]=>

  int(%d)

}

bool(true)

array(2) {

  ["total"]=>

  int(1024)

  ["free"]=>

  int(%d)

}

Done


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

Bug #53119 [Com]: LimitIterator(ArrayIterator)->seek() doesn't work correctly after OutOfBoundsE

[marc-bennewitz at arcor dot de]

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

 ID: 53119
 Comment by: marc-bennewitz at arcor dot de
 Reported by:marc-bennewitz at arcor dot de
 Summary:LimitIterator(ArrayIterator)->seek() doesn't work
 correctly after OutOfBoundsE
 Status: Open
 Type:   Bug
 Package:SPL related
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

The LimitIterator should have the same behavior as the inner iterator
(in this example ArrayIterator) but on ArrayIterator there is no need to
call rewind after an Exception.


Previous Comments:

[2010-10-21 11:50:29] johan...@php.net

The exception leaves the iterator in undefined behavior. That is
expected.


[2010-10-20 20:47:02] marc-bennewitz at arcor dot de

Description:

Seeking after an OutOfBoundException doesn't work without call of
rewind.

With php < 5.3 it works as expected.

Test script:
---
$it = new ArrayIterator(array('zf9396', 'foo', null));

$it->rewind();



try {

$it->seek(3);

} catch (OutOfBoundsException $e) {

var_dump($it->key());

$it->seek(0);

var_dump($it->key());

}





$lit = new LimitIterator($it, 0, 10);

try {

$lit->seek(3);

} catch (OutOfBoundsException $e) {

var_dump($lit->key());

$lit->seek(0);

var_dump($lit->key());

}





Expected result:

NULL

int(0)

NULL

int(0)

Actual result:
--
NULL

int(0)

NULL

NULL






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

[PHP-BUG] Bug #53119 [NEW]: LimitIterator(ArrayIterator)->seek() doesn't work correctly after OutOfBoundsE

[marc-bennewitz at arcor dot de]

From: 
Operating system: Linux
PHP version:  5.3.3
Package:  SPL related
Bug Type: Bug
Bug description:LimitIterator(ArrayIterator)->seek() doesn't work correctly 
after OutOfBoundsE

Description:

Seeking after an OutOfBoundException doesn't work without call of rewind.

With php < 5.3 it works as expected.

Test script:
---
$it = new ArrayIterator(array('zf9396', 'foo', null));

$it->rewind();



try {

$it->seek(3);

} catch (OutOfBoundsException $e) {

var_dump($it->key());

$it->seek(0);

var_dump($it->key());

}





$lit = new LimitIterator($it, 0, 10);

try {

$lit->seek(3);

} catch (OutOfBoundsException $e) {

var_dump($lit->key());

$lit->seek(0);

var_dump($lit->key());

}





Expected result:

NULL

int(0)

NULL

int(0)

Actual result:
--
NULL

int(0)

NULL

NULL

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

[PHP-BUG] Req #53100 [NEW]: Add function to list available vars

[marc-bennewitz at arcor dot de]

From: 
Operating system: 
PHP version:  5.3.3
Package:  Semaphore related
Bug Type: Feature/Change Request
Bug description:Add function to list available vars

Description:

It's not possible to get a list of available vars.

Test script:
---
shm_put_var($shm, 123, 'one');

ahm_put_var($shm, 456, 'two');

var_dump(shm_list_vars($shm));

Expected result:

array(2) {

  [0]=>

  int(123)

  [1]=>

  int(456)

}

*or*

array(2) {

  [123]=>

  string(3)"one"

  [456]=>

  string(3)"two"

}

Actual result:
--
PHP Fatal error:  Call to undefined function shm_list_vars() in ...

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

Bug #52971 [Csd]: PCRE-Meta-Characters not working with utf-8

[marc dot bennewitz at giata dot de]

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

 ID: 52971
 User updated by:marc dot bennewitz at giata dot de
 Reported by:marc dot bennewitz at giata dot de
 Summary:PCRE-Meta-Characters not working with utf-8
 Status: Closed
 Type:   Bug
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.3.3
 Assigned To:felipe
 Block user comment: N

 New Comment:

now it works fine :)

thanks


Previous Comments:

[2010-10-03 18:02:19] fel...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

In the last version of PCRE was added a flag PCRE_UCP, as states the
doc:

"In  PCRE,  by  default, \d, \D, \s, \S, \w, and \W recognize only ASCII
characters, even in UTF-8 mode. However, this can be changed by setting
the PCRE_UCP option."



Setting the flag we got:

array(1) {

  [0]=>

  array(1) {

[0]=>

array(2) {

  [0]=>

  string(6) "Wasser"

  [1]=>

  int(61)

}

  }

}

array(1) {

  [0]=>

  array(1) {

[0]=>

array(2) {

  [0]=>

  string(7) " Wasser"

  [1]=>

  int(60)

}

  }

}


[2010-10-03 18:01:40] fel...@php.net

Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=303963
Log: - Fixed bug #52971 (PCRE-Meta-Characters not working with utf-8)
#   In  PCRE,  by  default, \d, \D, \s, \S, \w, and \W recognize only
ASCII
#   characters, even in UTF-8 mode. However, this can be changed by
setting
#   the PCRE_UCP option.


[2010-10-03 11:02:15] cataphr...@php.net

I'm reopening as there's indeed a different behavior in Windows that I
can't yet quite explain,

----
[2010-10-03 10:21:34] marc dot bennewitz at giata dot de

There are some problems with it:

1. On windows it works as expected

2. With Unicode properties there is no word boundary (\w \W)

3. With the modifier "u" php knows that the subject is UTF-8

4. http://php.net/manual/regexp.reference.escape.php there is no note
for UTF-8 incompatibility



php.exe -i

...

iconv



iconv support => enabled

iconv implementation => "libiconv"

iconv library version => 1.11



Directive => Local Value => Master Value

iconv.input_encoding => ISO-8859-1 => ISO-8859-1

iconv.internal_encoding => ISO-8859-1 => ISO-8859-1

iconv.output_encoding => ISO-8859-1 => ISO-8859-1

...

pcre



PCRE (Perl Compatible Regular Expressions) Support => enabled

PCRE Library Version => 8.02 2010-03-19



Directive => Local Value => Master Value

pcre.backtrack_limit => 10 => 10

pcre.recursion_limit => 10 => 10

...


[2010-10-02 20:26:05] cataphr...@php.net

This is by design, it's the way \b and \w are defined in PCRE.



You'll have to use another strategy, like look behind and unicode
character properties.




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


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

Bug #52971 [Bgs]: PCRE-Meta-Characters not working with utf-8

[marc dot bennewitz at giata dot de]

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

 ID: 52971
 User updated by:marc dot bennewitz at giata dot de
 Reported by:marc dot bennewitz at giata dot de
 Summary:PCRE-Meta-Characters not working with utf-8
 Status: Bogus
 Type:   Bug
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

There are some problems with it:

1. On windows it works as expected

2. With Unicode properties there is no word boundary (\w \W)

3. With the modifier "u" php knows that the subject is UTF-8

4. http://php.net/manual/regexp.reference.escape.php there is no note
for UTF-8 incompatibility



php.exe -i

...

iconv



iconv support => enabled

iconv implementation => "libiconv"

iconv library version => 1.11



Directive => Local Value => Master Value

iconv.input_encoding => ISO-8859-1 => ISO-8859-1

iconv.internal_encoding => ISO-8859-1 => ISO-8859-1

iconv.output_encoding => ISO-8859-1 => ISO-8859-1

...

pcre



PCRE (Perl Compatible Regular Expressions) Support => enabled

PCRE Library Version => 8.02 2010-03-19



Directive => Local Value => Master Value

pcre.backtrack_limit => 10 => 10

pcre.recursion_limit => 10 => 10

...


Previous Comments:

[2010-10-02 20:26:05] cataphr...@php.net

This is by design, it's the way \b and \w are defined in PCRE.



You'll have to use another strategy, like look behind and unicode
character properties.


[2010-10-02 17:58:41] marc dot bennewitz at giata dot de

Description:

PCRE-Meta-Characters like \b \w not working with unicode strings.



PHP-5.3.3 (32Bit)

pcre



PCRE (Perl Compatible Regular Expressions) Support => enabled

PCRE Library Version => 8.02 2010-03-19



Directive => Local Value => Master Value

pcre.backtrack_limit => 10 => 10

pcre.recursion_limit => 10 => 10



iconv



iconv support => enabled

iconv implementation => glibc

iconv library version => 2.10.1



Directive => Local Value => Master Value

iconv.input_encoding => ISO-8859-1 => ISO-8859-1

iconv.internal_encoding => ISO-8859-1 => ISO-8859-1

iconv.output_encoding => ISO-8859-1 => ISO-8859-1



Test script:
---


  array(1) {

[0]=>

array(2) {

  [0]=>

  string(6) "Wasser"

  [1]=>

  int(61)

}

  }

}

array(1) {

  [0]=>

  array(1) {

[0]=>

array(2) {

  [0]=>

  string(7) " Wasser"

  [1]=>

  int(60)

}

  }

}

Actual result:
--
array(1) {

  [0]=>

  array(2) {

[0]=>

array(2) {

  [0]=>

  string(6) "wasser"

  [1]=>

  int(17)

}

[1]=>

array(2) {

  [0]=>

  string(6) "Wasser"

  [1]=>

  int(61)

}

  }

}

array(1) {

  [0]=>

  array(2) {

[0]=>

array(2) {

  [0]=>

  string(8) "ßwasser"

  [1]=>

  int(15)

}

[1]=>

array(2) {

  [0]=>

  string(7) " Wasser"

  [1]=>

  int(60)

}

  }

}






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

[PHP-BUG] Bug #52971 [NEW]: PCRE-Meta-Characters not working with utf-8

[marc dot bennewitz at giata dot de]

From: 
Operating system: Linux
PHP version:  5.3.3
Package:  PCRE related
Bug Type: Bug
Bug description:PCRE-Meta-Characters not working with utf-8

Description:

PCRE-Meta-Characters like \b \w not working with unicode strings.



PHP-5.3.3 (32Bit)

pcre



PCRE (Perl Compatible Regular Expressions) Support => enabled

PCRE Library Version => 8.02 2010-03-19



Directive => Local Value => Master Value

pcre.backtrack_limit => 10 => 10

pcre.recursion_limit => 10 => 10



iconv



iconv support => enabled

iconv implementation => glibc

iconv library version => 2.10.1



Directive => Local Value => Master Value

iconv.input_encoding => ISO-8859-1 => ISO-8859-1

iconv.internal_encoding => ISO-8859-1 => ISO-8859-1

iconv.output_encoding => ISO-8859-1 => ISO-8859-1



Test script:
---


  array(1) {

[0]=>

array(2) {

  [0]=>

  string(6) "Wasser"

  [1]=>

  int(61)

}

  }

}

array(1) {

  [0]=>

  array(1) {

[0]=>

array(2) {

  [0]=>

  string(7) " Wasser"

  [1]=>

  int(60)

}

  }

}

Actual result:
--
array(1) {

  [0]=>

  array(2) {

[0]=>

array(2) {

  [0]=>

  string(6) "wasser"

  [1]=>

  int(17)

}

[1]=>

array(2) {

  [0]=>

  string(6) "Wasser"

  [1]=>

  int(61)

}

  }

}

array(1) {

  [0]=>

  array(2) {

[0]=>

array(2) {

  [0]=>

  string(8) "ßwasser"

  [1]=>

  int(15)

}

[1]=>

array(2) {

  [0]=>

  string(7) " Wasser"

  [1]=>

  int(60)

}

  }

}

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

Bug #31323 [Com]: session file permissions differ randomly

[marc at iacomputing dot co dot uk]

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

 ID: 31323
 Comment by: marc at iacomputing dot co dot uk
 Reported by:julien dot mathieu at gmail dot com
 Summary:session file permissions differ randomly
 Status: No Feedback
 Type:   Bug
 Package:Session related
 Operating System:   Linux
 PHP Version:5.1.2, 4.3.9
 Block user comment: N

 New Comment:

This problem still exists in 5.2.9.



Sessions are being created with -rw--- permissions. 



The session is being created on the first site and the when a user
visits 

another site on the same server with a different IP address the server
is trying 

to use the same session file but cannot access it.



Running WHM 11.26.8 &

CENTOS 5.5 x86_64 standard



Sites have different IP addresses.



Strangely the problem does not exist when users visit
WWW.domainname.co.uk 

first. It only occurs when user first visit the site without the "www".



So when they visit the second site secure.domainname.co.uk after
visiting 

domainname.co.uk. They cannot write to their session files on the
server.


Previous Comments:

[2010-07-07 14:46:56] yanusdnd at inbox dot ru

Yes. i've got the same problem. rebooting was help for first 2 or 3
request and 

again r-- --- ---. You can see that at http://aquafaq.ru";>aquafaq.ru.

First time - OK but all others FAIL: Warning: session_start()
[function.session-

start]: open(/var/lib/php5/sess_d81882c054eff34d32ae1b247bb64f84,
O_RDWR) failed: 

Permission denied (13) in


[2009-09-08 17:56:34] maciejsliwa at op dot pl

I have the same problem with O_RDWR, it happend in 20% of usage. It
strange, because on the same configuration, but only on diffrent
computer it works fine.

Computer on which i have problems

Notebook HP 6153ea dualcore 1,66Ghz

Windows XP Media Center Edition

PHP 5.3.0

server Apache



Server was instaled by EasyPHP 2.0



the second computer which configuration is identical is

AMD Athlon 1Ghz

Windows XP Profesional

PHP 5.3.0

server Apache

and on this its works fine



[Tue Sep 08 19:44:37 2009] [error] [client 127.0.0.1] PHP Warning: 
session_start() [function.session-start]:
open(C:\\DOCUME~1\\Maciek\\LOCALS~1\\Tempsess_jcje64e16gqqtpktra8jndo990,
O_RDWR) failed: Permission denied (13) in C:\\Program
Files\\EasyPHP3_1\\www\\Magazyn\\magazynMain.php on line 3, referer:
http://127.0.0.1/Magazyn/magazyn.php


[2009-03-31 14:47:16] prikid at gmail dot com

We are experiencing similar problem with php 5.2.6 on freebsd and red
hat linux


[2008-08-12 16:21:03] linus dot norton at assertis dot co dot uk

I have also encountered this twice on redhat running apache 2.2.6 and
php 5.2.6.



Why has this been closed, no feedback was requested then the ticket is
just closed saying no feedback has been given.


[2006-11-09 14:44:35] mg at iceni dot pl

I can confirm this bug happening on php 4.4.2 build as apache 2 (with
prefork) module. It's extremaly difficult to reproduce, but with little
research it seems to be somehow umask related. 



The following is from strace running on a apache process that creates
the files with wrong permissions 



open("/tmp/sess_5b2929b94cf141335d0b2d1e5a38fc29", O_RDWR|O_CREAT, 0600)
= 186

fstat64(186, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0



So php creates file with 600 permissions but it has only 400 in final.
Note that's happening very rarely, normally file is created with 600. 



I didn't have luck tracing how and when umask is changing during request
processing (probably something is changing it prior to the request, so
possibly it's not even php related), but I tried to make the following
very dirty workaround in ext/session/mod_files.c:





@@ -138,6 +138,7 @@

 static void ps_files_open(ps_files *data, const char *key TSRMLS_DC)

 {

char buf[MAXPATHLEN];

+   mode_t orig_mask;



if (data->fd < 0 || !data->lastkey || strcmp(key,
data->lastkey)) {

if (data->lastkey) {

@@ -156,8 +157,10 @@



data->lastkey = estrdup(key);



+   orig_mask = umask(0);

data->fd = VCWD_OPEN_MODE(buf, O_CREAT | O_RDWR |
O_BINARY, 0600);

-

+   umask(orig_mask);

+



No matter how ugly it is - it seems to do the job and session files with
wrong permissions are no longer created (this workaround is probably bad
idea on threaded severs though).

-

#48585 [Com]: com_load_typelib holds reference, fails on second call

[marc at parknpool dot com]

 ID:   48585
 Comment by:   marc at parknpool dot com
 Reported By:  robert dot johnson at icap dot com
 Status:   Open
 Bug Type: COM related
 Operating System: Win XP sp3
 PHP Version:  5.2.9
 New Comment:

I am having the same problem.  I use com_load_typelib to load COM
constants.  The result of calling com_load_typelib always returns true. 
However, the constants are defined on the first call and undefined for
each subsequent call to the page I am testing.  This is true when I go
away from the page or switch browsers.

Apparently restarting the web server (Apache) resets the system state
and I can see the constants again, but on the first call only.

OS: Windows Server 2008
PHP Version: 5.2.6
In php.ini:

com.allow_dcom = true
com.autoregister_typelib = true
com.autoregister_casesensitive = false
com.autoregister_verbose = true


Previous Comments:


[2009-06-17 15:19:03] robert dot johnson at icap dot com

Description:

com_load_typelib successfully loads a type library defintitions on its
first call.

It fails on the second call, and the previous definitions disappear.

Other points:
First call holds a reference to the type library which does not get
released until the web server (Apache 2.2) is stopped.  If you're
creating define()'s, why do you need to hold a library reference - you
could load the types then release the references?

This behaviour is the same when php.ini contains
'com.autoregister_typelib=1', instead of calling com_load_typelib.


Reproduce code:
---
This uses a private COM object, but if you want a copy it's no
problem.


function test()
{
com_load_typelib('{8F387CCB-379F-4F13-9470-9D04DF3B04F8},1,0');
$domain = '';
$dns = 'some_u...@domain.com';
$wincall = new COM('wincall.wincall');
$snu = $wincall->LookupAccount('', $dns, $domain);
echo 'SidTypeUser == ' . SidTypeUser . "\r\n";
}

test();
/

Run this script twice...

Expected result:

// first call of script:
SidTypeUser == 1

// second call of script:
SidTypeUser == 1

Actual result:
--
// first call of script:
SidTypeUser == 1

// second call of script:
SidTypeUser == SidTypeUser





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

#48614 [Com]: Loading "pdo_sqlite.so" fails: undefined symbol: sqlite3_libversion

[marc dot bennewitz at giata dot de]

 ID:   48614
 Comment by:   marc dot bennewitz at giata dot de
 Reported By:  kaspernj at gmail dot com
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Ubuntu Jaunty
 PHP Version:  5.3.0RC4
 Assigned To:  scottmac
 New Comment:

I have the same problem with suse 10.x 32/64 bit using php 5.3.0/1
stable.

My configure is:
cd "/home/worker/download/php-5.3.1"
./configure \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mm \
--with-mysql=shared,/usr/local \
--with-mysqli=shared,/usr/local/bin/mysql_config \
--with-sqlite=shared \
--with-sqlite3=shared \
--enable-pdo=shared \
--with-pdo-mysql=shared,/usr/local \
--with-pdo-sqlite=shared \
--with-libxml-dir=/usr/local/lib \
--enable-soap \
--with-zlib \
--disable-cgi \
--with-gd=shared \
--with-freetype-dir \
--with-jpeg-dir=/usr/lib \
--enable-gd-native-ttf \
--enable-exif \
--with-xsl \
--with-mcrypt \
--with-openssl \
--enable-mbstring \
--enable-mbregex \
--enable-ftp=shared \
--with-kerberos \
--enable-zip

And extension order:
extension=pdo.so
extension=sqlite.so
extension=sqlite3.so
extension=mysql.so
extension=mysqli.so
extension=pdo_mysql.so
extension=pdo_sqlite.so

Additionally if I load sqlite.so before pdo.so than I get 1 more
error:
PHP Warning:  PHP Startup: Unable to load dynamic library
'/usr/local/lib/php/extensions/no-debug-non-zts-20090626/sqlite.so' -
/usr/local/lib/php/extensions/no-debug-non-zts-20090626/sqlite.so:
undefined symbol: php_pdo_unregister_driver in Unknown on line 0

Warning: PHP Startup: Unable to load dynamic library
'/usr/local/lib/php/extensions/no-debug-non-zts-20090626/sqlite.so' -
/usr/local/lib/php/extensions/no-debug-non-zts-20090626/sqlite.so:
undefined symbol: php_pdo_unregister_driver in Unknown on line 0


Previous Comments:


[2009-11-23 22:48:24] koubel at volny dot cz

i dot galic: yes, but if I use bundled sqlite, without /usr in
configure, bug is still here. When I use --enable-pdo=shared
--with-pdo-sqlite=shared
"configure" and "make" phases are ok, but when I try to use "make test"
all tests fails, because warning:
dl(): Unable to load dynamic library '.../pdo_sqlite.so' -
.../pdo_sqlite.so: undefined symbol: sqlite3_libversion

is produced on every test.

So bug is still there (tested php 5.3.1 on Debian Lenny). Using own
sqlite is workaround I think.



[2009-11-22 23:37:04] i dot galic at brainsware dot org

from pdo_sqlite.la
# Libraries that this one depends upon.
dependency_libs=' -lrt'

from pdo_pgsql.la:
# Libraries that this one depends upon.
dependency_libs=' -lpq'

Makes sense. The obvious fix (or workaround) would be to do:

--with-sqlite=shared,/usr --with-pdo-pgsql=shared,/usr etc..

In Debian, make sure to have libsqlite0-dev and libsqlite3-dev
installed



[2009-11-11 17:12:22] kenashkov at gmail dot com

I'm able to reproduce this with 5.3.1 RC3 on debian 5.



[2009-08-23 00:22:27] koubel at volny dot cz

yes, same problem with php 5.3.0 final instalation on debian stable



[2009-07-09 18:18:07] dkepplinger at gmail dot com

I have the same problem with PHP 5.3 on Debian 5.0.2 when loading the
pdo_sqlite.so extension in the config file.



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/48614

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

#50813 [Fbk->Opn]: __get called on isset($obj->test[0]) (__isset not tested before)

[marc dot bennewitz at giata dot de]

 ID:   50813
 User updated by:  marc dot bennewitz at giata dot de
 Reported By:  marc dot bennewitz at giata dot de
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.3.1
 New Comment:

Thats the same:

>php -v
PHP 5.3.3-dev (cli) (built: Jan 21 2010 12:52:05)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

>php test.php
PHP Notice:  Key "test" does not exist in /tmp/test.php on line 14

Notice: Key "test" does not exist in /tmp/test.php on line 14
bool(false)


Previous Comments:


[2010-01-21 09:59:53] j...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/



----

[2010-01-21 09:10:17] marc dot bennewitz at giata dot de

Description:

On testing if an array key is available on an overloaded object
variable it doesn't check __isset before calling __get to get the
variable for checking the array key.

Reproduce code:
---
class MyClass
{

public function __isset($varname)
{
echo 'isset' . PHP_EOL;
return false;
}

public function __get($varname)
{
trigger_error('Key "' . $varname . '" does not exist',
E_USER_NOTICE);
}

}

$obj = new MyClass();
var_dump( isset($obj->test[0]) );

Expected result:

isset
bool(false)

Actual result:
--
PHP Notice:  Key "test" does not exist in /tmp/test.php on line 14

Notice: Key "test" does not exist in /tmp/test.php on line 14
bool(false)





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

#50813 [NEW]: __get called on isset($obj->test[0]) (__isset not tested before)

[marc dot bennewitz at giata dot de]

From: marc dot bennewitz at giata dot de
Operating system: Linux
PHP version:  5.3.1
PHP Bug Type: Scripting Engine problem
Bug description:  __get called on isset($obj->test[0])  (__isset not tested 
before)

Description:

On testing if an array key is available on an overloaded object variable
it doesn't check __isset before calling __get to get the variable for
checking the array key.

Reproduce code:
---
class MyClass
{

public function __isset($varname)
{
echo 'isset' . PHP_EOL;
return false;
}

public function __get($varname)
{
trigger_error('Key "' . $varname . '" does not exist',
E_USER_NOTICE);
}

}

$obj = new MyClass();
var_dump( isset($obj->test[0]) );

Expected result:

isset
bool(false)

Actual result:
--
PHP Notice:  Key "test" does not exist in /tmp/test.php on line 14

Notice: Key "test" does not exist in /tmp/test.php on line 14
bool(false)

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

#50354 [NEW]: Syntax inconsistency in function (call & definition) arguments

[jean dot marc dot leger at gmail dot com]

From: jean dot marc dot leger at gmail dot com
Operating system: Gnu/Linux i686
PHP version:  5.2.11
PHP Bug Type: Scripting Engine problem
Bug description:  Syntax inconsistency in function (call & definition) arguments

Description:

PHP has always tolerated one trailing comma (,) at the end of array
declaration, producing no error. I assume this is intended to easily
generate array-syntax compliant php code in a loop.


It would be great to have PHP behaving the same way in function
declaration and function call parameters contexts.

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

#50161 [Bgs]: foreach needs to be fixed

[marc at perkel dot com]

 ID:   50161
 User updated by:  marc at perkel dot com
 Reported By:  marc at perkel dot com
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

Block scope variables is NOT the only solution. In this case if the AS
variable were unset at the beginning of the loop it would fix the
problem.


Previous Comments:


[2009-11-12 23:55:16] ras...@php.net

Note that you are treating references as if they are pointers in your
argument.  They are not pointers.  They are entries in the symbol table
that reference other entries in the symbol table.  So when you do
unset($x) you are removing that symbol table entry.  And in your
non-reference example:

$y = "some test";

foreach ($myarray as $y) {
   print "$y\n";
}

Here $y is a symbol table entry referencing a string containing "some
test".  On the first iteration you essentially do:

$y = $myarray[0];  // Not necessarily 0, just the 1st element

So now the storage associated with $y is overwritten by the value from
$myarray.  If $y is associated with some other storage through a
reference, that storage will be changed.

Now let's say you do this:

$myarray = array("Test");
$a = "A string";
$y = &$a;

foreach ($myarray as $y) {
   print "$y\n";
}

Here $y is associated with the same storage as $a through a reference
so when the first iteration does:

$y = $myarray[0];

The only place that "Test" string can go is into the storage associated
with $y.  There is no other place for it to go.  It is clean and
consistent.  And this is the example of what would break if foreach
magically broke the reference.  Never mind the nightmare of
inconsistencies for other types of loops, like a
while(list($k,$v)=each($myarray)) { } loop.  Do we then break the $k and
$v references in a list() call if it happens to be called in the context
of a while loop?  Or is a while-each loop now suddenly very different
from a foreach loop?

I think you just have to take our word for it, even if you don't agree,
that it is correct as it is even though it can trip people up.  The only
clean way to fix this would be to introduce block-scoped variables, but
that is well beyond the scope of this bug report.




[2009-11-12 23:06:34] marc at perkel dot com

Give me an example of code it would break if you deleted the reference
at the beginning of a foreach loop. I'm not suggesting that it be
deleted at the end. And foreach will delete a variable if it is already
set to a value. For example:

$y = "some test";

foreach ($myarray as $y) {
   print "$y\n";
}


In this case $y is overridden. So it is inconsistent not to override a
reference at the beginning of foreach.

There are other cases where references are deleted. If you do:

unset($x);

It unsets $x - not what $x is pointing to.

The point is - the results of the example I posts here makes PHP
laughable out here in the real world. I think it's a bad idea for PHP to
fail the laugh test.



[2009-11-12 22:56:36] ras...@php.net

Arbitrarily deleting a reference would break a lot of code.  What you
are looking for a block-scope variables.  We do not have those in PHP.



[2009-11-12 21:44:54] marc at perkel dot com

If it's been reported several times then you aren't listening. It is a
bug. This is why open source has a bad name because people don't fix
what is obviously a bug.



[2009-11-12 21:36:55] j...@php.net

Already reported several times, already decided to be the correct
behavior which is also documented. 



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/50161

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

#50161 [Bgs]: foreach needs to be fixed

[marc at perkel dot com]

 ID:   50161
 User updated by:  marc at perkel dot com
 Reported By:  marc at perkel dot com
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

Give me an example of code it would break if you deleted the reference
at the beginning of a foreach loop. I'm not suggesting that it be
deleted at the end. And foreach will delete a variable if it is already
set to a value. For example:

$y = "some test";

foreach ($myarray as $y) {
   print "$y\n";
}


In this case $y is overridden. So it is inconsistent not to override a
reference at the beginning of foreach.

There are other cases where references are deleted. If you do:

unset($x);

It unsets $x - not what $x is pointing to.

The point is - the results of the example I posts here makes PHP
laughable out here in the real world. I think it's a bad idea for PHP to
fail the laugh test.


Previous Comments:


[2009-11-12 22:56:36] ras...@php.net

Arbitrarily deleting a reference would break a lot of code.  What you
are looking for a block-scope variables.  We do not have those in PHP.

----

[2009-11-12 21:44:54] marc at perkel dot com

If it's been reported several times then you aren't listening. It is a
bug. This is why open source has a bad name because people don't fix
what is obviously a bug.



[2009-11-12 21:36:55] j...@php.net

Already reported several times, already decided to be the correct
behavior which is also documented. 

----

[2009-11-12 20:45:33] marc at perkel dot com

Description:

When using foreach and looping through an array the second time if the
index variable isn't unset the results are that the referenced variables
is used as the index rather than the named variable.

The issue can be solved if when the foreach is set up that it does an
unset on the variable passed as the "as" variable. PHP should be changed
to unset the parameter passed as the index into the array.


Reproduce code:
---
$myarray = array("one","two","three","four");

foreach ($myarray as &$x) {
   $x = "$x -";
   print "$x\n";
}

print "\n";

foreach ($myarray as $x) {
   print "$x\n";
}


Expected result:

one -
two -
three -
four -

one -
two -
three -
four -

Actual result:
--
one -
two -
three -
four -

one -
two -
three -
three -





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

#50161 [Bgs]: foreach needs to be fixed

[marc at perkel dot com]

 ID:   50161
 User updated by:  marc at perkel dot com
 Reported By:  marc at perkel dot com
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

If it's been reported several times then you aren't listening. It is a
bug. This is why open source has a bad name because people don't fix
what is obviously a bug.


Previous Comments:


[2009-11-12 21:36:55] j...@php.net

Already reported several times, already decided to be the correct
behavior which is also documented. 



[2009-11-12 20:45:33] marc at perkel dot com

Description:

When using foreach and looping through an array the second time if the
index variable isn't unset the results are that the referenced variables
is used as the index rather than the named variable.

The issue can be solved if when the foreach is set up that it does an
unset on the variable passed as the "as" variable. PHP should be changed
to unset the parameter passed as the index into the array.


Reproduce code:
---
$myarray = array("one","two","three","four");

foreach ($myarray as &$x) {
   $x = "$x -";
   print "$x\n";
}

print "\n";

foreach ($myarray as $x) {
   print "$x\n";
}


Expected result:

one -
two -
three -
four -

one -
two -
three -
four -

Actual result:
--
one -
two -
three -
four -

one -
two -
three -
three -





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

#50161 [NEW]: foreach needs to be fixed

[marc at perkel dot com]

From: marc at perkel dot com
Operating system: Linux
PHP version:  5.2.11
PHP Bug Type: Scripting Engine problem
Bug description:  foreach needs to be fixed

Description:

When using foreach and looping through an array the second time if the
index variable isn't unset the results are that the referenced variables is
used as the index rather than the named variable.

The issue can be solved if when the foreach is set up that it does an
unset on the variable passed as the "as" variable. PHP should be changed to
unset the parameter passed as the index into the array.


Reproduce code:
---
$myarray = array("one","two","three","four");

foreach ($myarray as &$x) {
   $x = "$x -";
   print "$x\n";
}

print "\n";

foreach ($myarray as $x) {
   print "$x\n";
}


Expected result:

one -
two -
three -
four -

one -
two -
three -
four -

Actual result:
--
one -
two -
three -
four -

one -
two -
three -
three -

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

#50029 [NEW]: Weird invoke issue on class as property

[marc dot gray at gmail dot com]

From: marc dot gray at gmail dot com
Operating system: Ubuntu 9.04
PHP version:  5.3.0
PHP Bug Type: Class/Object related
Bug description:  Weird invoke issue on class as property

Description:

Placing a class with an __invoke method as a property inside another 
class seems to nullify the invokeability of the original class.

Tested on:
Ubuntu 9.04, PHP 5.3.0
CentOS 5.3, PHP 5.2.11 ionCube / Suhosin

Reproduce code:
---
class a { 
  function __construct() { } 
  function __invoke() { echo("Invoked\n"); } 
} 

$a = new a(); 
$a(); 
// Prints: Invoked 

class b { 
  private $x; 

  function __construct() { 
$this->x = new a(); 
$this->x(); 
  } 
} 

$b = new b(); 
// Issues error: undefined method b::x  

Expected result:

I expect "new b()" construct to call the class a invoke

Actual result:
--
Undefined method - it doesn't seem to recognise the invokeable class 
property as actually invokeable.

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

#49906 [NEW]: LimitIterator doesn't work with un-/serialize

[marc-bennewitz at arcor dot de]

From: marc-bennewitz at arcor dot de
Operating system: Linux
PHP version:  5.3SVN-2009-10-16 (snap)
PHP Bug Type: SPL related
Bug description:  LimitIterator doesn't work with un-/serialize

Description:

Serializing of LimitIterator doesn't work.


Reproduce code:
---
$it = new ArrayIterator(array('test' => 'test'));

$limitit = new LimitIterator($it, 0, 10);
var_dump($limitit);
var_dump($limitit->getInnerIterator());

$limititSer = serialize($limitit);
var_dump($limititSer);

$limitit = unserialize($limititSer);
var_dump($limitit);
var_dump($limitit->getInnerIterator());

Expected result:

object(LimitIterator)#2 (0) {
  /* some content */
}
object(ArrayIterator)#1 (1) {
  ["storage":"ArrayIterator":private]=>
  array(1) {
["test"]=>
string(4) "test"
  }
}
string(25) "O:13:"LimitIterator":0:{...}"
object(LimitIterator)#3 (0) {
  /* some content */
}
object(ArrayIterator)#1 (1) {
  ["storage":"ArrayIterator":private]=>
  array(1) {
["test"]=>
string(4) "test"
  }
}

Actual result:
--
object(LimitIterator)#2 (0) {
}
object(ArrayIterator)#1 (1) {
  ["storage":"ArrayIterator":private]=>
  array(1) {
["test"]=>
string(4) "test"
  }
}
string(25) "O:13:"LimitIterator":0:{}"
object(LimitIterator)#3 (0) {
}
NULL

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

#48976 [Bgs]: Missing Error on serialize resources with serialize & wddx_serialize_value

[marc-bennewitz at arcor dot de]

 ID:   48976
 User updated by:  marc-bennewitz at arcor dot de
 Reported By:  marc-bennewitz at arcor dot de
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: WinXP
 PHP Version:  5.3.0
 New Comment:

http://php.net/manual/function.serialize.php
-> There is the following message documented for the value argument:
"The value to be serialized. serialize()  handles all types, except the
resource-type. ..."
-> There is no information to store resources as an integer value


Previous Comments:


[2009-07-20 10:59:13] j...@php.net

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





[2009-07-19 18:05:12] marc-bennewitz at arcor dot de

Description:

Missing Error on serialize resources with serialize and
wddx_serialize_value

Reproduce code:
---
$value = fopen(__FILE__, 'rb');
var_dump(serialize($value));
var_dump(wddx_serialize_value($value));


Expected result:

FALSE and PHP-Notice-Message for both serialize calls

Actual result:
--
string(4) "i:0;"
string(61) ""





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

#48976 [NEW]: Missing Error on serialize resources with serialize & wddx_serialize_value

[marc-bennewitz at arcor dot de]

From: marc-bennewitz at arcor dot de
Operating system: WinXP
PHP version:  5.3.0
PHP Bug Type: Scripting Engine problem
Bug description:  Missing Error on serialize resources with serialize & 
wddx_serialize_value

Description:

Missing Error on serialize resources with serialize and
wddx_serialize_value

Reproduce code:
---
$value = fopen(__FILE__, 'rb');
var_dump(serialize($value));
var_dump(wddx_serialize_value($value));


Expected result:

FALSE and PHP-Notice-Message for both serialize calls

Actual result:
--
string(4) "i:0;"
string(61) ""

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

#47115 [Opn]: Can't use flag LOCK_SH in file_get_contents

[marc dot bennewitz at giata dot de]

 ID:  47115
 User updated by: marc dot bennewitz at giata dot de
-Summary: Can't use flag LOCK_SH
 Reported By: marc dot bennewitz at giata dot de
 Status:  Open
 Bug Type:Feature/Change Request
 PHP Version: 6CVS-2009-01-15 (snap)
 New Comment:

change subject: Can't use flag LOCK_SH in file_get_contents


Previous Comments:


[2009-01-15 15:32:14] marc dot bennewitz at giata dot de

Description:

similar to file_put_contents can use LOCK_EX






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

#47115 [NEW]: Can't use flag LOCK_SH

[marc dot bennewitz at giata dot de]

From: marc dot bennewitz at giata dot de
Operating system: 
PHP version:  6CVS-2009-01-15 (snap)
PHP Bug Type: Feature/Change Request
Bug description:  Can't use flag LOCK_SH

Description:

similar to file_put_contents can use LOCK_EX


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

#41237 [Com]: XOR problem

[lombard-marc at wanadoo dot fr]

 ID:   41237
 Comment by:   lombard-marc at wanadoo dot fr
 Reported By:  victorepand at gmail dot com
 Status:   No Feedback
 Bug Type: Math related
 Operating System: Linux
 PHP Version:  5.2.1
 New Comment:

Same bug happens on my production server PHP 5.2.0-8 on Linux
It is ok on the development server PHP 5.2.6 on Windows.
Impacts blowfish algorithms (2 servers get different results)


Previous Comments:


[2008-02-29 21:53:51] dochoncho at gmail dot com

Reproduced using PHP/5.2.3-1ubuntu6.3

What fun.



[2007-08-29 09:22:22] php dot ydyoda at spamgourmet dot com

For information:

Same bug on PHP 4.3.11
But no probleme with PHP 4.3.5



[2007-05-08 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2007-04-30 13:09:45] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2007-04-30 09:15:07] victorepand at gmail dot com

Description:

I am finding a difference between the same bitwise arithmetic from one
server to the next when using PHP. What's more, this bitwise arithmetic
is necessary for the PHP script to run, so as a result it will only
function on one server, but not the other.

Here is an example I am using to demonstrate this:

if ((43814 ^ -4738698913)!=-443704711) print "incorrect result";
else print "correct result";

The (^) operator is an XOR bitwise arithmetic function as shown here:
http://us2.php.net/manual/en/language.operators.bitwise.php
and I am required to use numbers like the ones shown.

On one server, I have tried both PHP 4.4.0 and PHP 5.1.0RC1 and the
math works correctly for both (the correct answer as shown above is
-443704711). But on another server, I have tried the same math with both
PHP 4.4.6 and PHP 5.2.1, and it does not work correctly with either
version of PHP! The result I get at that server is: -2147439834.

I have no idea what could be the problem, but I can show you the PHP
Info for both servers and perhaps you can detect what might be the
difference?

Here is the PHP Info for the server that works correctly using PHP
5.1.0RC1:
http://www.buycellularphones.info/cron/special/info.php

Here is the PHP Info for the other server using PHP 5.2.1 that does not
work correctly:
http://www.customdesignpostcards.com/cron/special/info.php


Reproduce code:
---
if ((43814 ^ -4738698913)!=-443704711) print "incorrect result";
else print "correct result";

Expected result:

correct result

Actual result:
--
incorrect result





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

#45824 [Bgs]: loadXML moves entity references from attribute value to before element

[marc at mongenet dot ch]

 ID:   45824
 User updated by:  marc at mongenet dot ch
 Reported By:  marc at mongenet dot ch
 Status:   Bogus
 Bug Type: DOM XML related
 Operating System: Linux
 PHP Version:  5.2.6
 New Comment:

In the Extensible Markup Language (XML) 1.0 (Fourth Edition) W3C
Recommendation, chapter 4.1 Character and Entity References, it is
written:
"Note that non-validating processors are not obligated to to read and
process entity declarations occurring in parameter entities or in the
external subset; for such documents, the rule that an entity must be
declared is a well-formedness constraint only if standalone='yes'."

What we have in this example is : "Entity 'eacute' is not defined in
Entity" -> i.e. it is not defined in the parsed data. That's because it
is defined in the external subset. Okay, I admit I didn't write an
external subset, but it makes no difference because the XML processor
does not try to read it because I haven't set
$doc->resolveExternals=TRUE.

The XML processor should either stop on a fatal error or produce a
correct DOM (that't a general rule for XML processors). But producing a
wrong DOM is a no-no. BTW, if the é entity reference appears in
the text instead of an attribute value, then the DOM is correctly built.


Previous Comments:


[2008-08-15 06:34:07] [EMAIL PROTECTED]

You should read the warning, it produces:

Warning: DOMDocument::loadXML(): Entity 'eacute' not defined in Entity,

line: 2 in /Users/chregu/tmp/foo.php on line 6

eacute is not a entity which is defined by default (there are only 5 of

them)



[2008-08-14 17:59:11] marc at mongenet dot ch

Description:

When an attribute value contains an entity reference (like
a="é"), loadXML() moves this entity out of the attribute, just
before the owner element.

Reproduce code:
---
$doc = new DOMDocument();
$xml = ''."\n". # DOCTYPE just to appear
well-formed
   ''."\n";
$doc->loadXML($xml);
echo '', htmlspecialchars($doc->saveXML()), '';


Expected result:






Actual result:
--


é






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

#45824 [NEW]: loadXML moves entity references from attribute value to before element

[marc at mongenet dot ch]

From: marc at mongenet dot ch
Operating system: Linux
PHP version:  5.2.6
PHP Bug Type: DOM XML related
Bug description:  loadXML moves entity references from attribute value to 
before element

Description:

When an attribute value contains an entity reference (like a="é"),
loadXML() moves this entity out of the attribute, just before the owner
element.

Reproduce code:
---
$doc = new DOMDocument();
$xml = ''."\n". # DOCTYPE just to appear
well-formed
   ''."\n";
$doc->loadXML($xml);
echo '', htmlspecialchars($doc->saveXML()), '';


Expected result:






Actual result:
--


é


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

#42849 [Com]: Configuration File (php.ini) Path incorrect

[marc dot gerardi at gmail dot com]

 ID:   42849
 Comment by:   marc dot gerardi at gmail dot com
 Reported By:  inglis-php at yahoo dot com dot au
 Status:   No Feedback
 Bug Type: *General Issues
 Operating System: win xp pro
 PHP Version:  5.2.4
 New Comment:

This is occurring in PHP Version 5.2.6 as well.

Running into the same issue...php info output:

Configuration File (php.ini) Path   C:\WINDOWS
Loaded Configuration File   (none) 

VPS Container:
Windows 2003 Server
SP2
IIS 6.0
PHP Version 5.2.6


Previous Comments:


[2008-07-13 12:30:26] pip at pip dot co dot za

Ok... I am now at the end of my patience with this. I've followed every
single post I could find on the topic, and not one of them has worked
for me.

After reading orbital_man's post, I thought I finally tracked down a
fix, but even that hasn't worked for me. My setup is like such:

PHP 5.2.6
Windows Vista Ultimate (IIS 6)

I've configured PHP using the ZIP archive and manual installation. I've
been installing and running PHP this way since I started using PHP 6
years ago, and never had problems. I can do it with my eyes closed and
by typing with my nose, so I know I am following every step I should be,
needless to mention that I do follow the installation manual every time
for in case there are changes.

In conclusion, PHP does not see my ini file, and whatever extensions I
load and configure in php does not have affect on my installation, which
is the issue, because I need MySQL loaded. Somebody please give us some
guidence here.

Thanx.

Pip



[2008-05-20 20:15:08] james at thundermonkey dot net

I've found that the positioning of the PHPIniDir within httpd.conf
makes a difference - place it at the end and it loads the correct
php.ini, but place it towards the top of httpd.conf results in the no
php.ini being loaded at all.

Also be sure to explicitly define your extension_dir directive in
php.ini to load extensions correctly.



[2008-04-20 04:46:25] orbital_man at hotmail dot com

Additional test case:

OS: Windows XP Pro
Webserver: IIS 5.1
PHP: 5.2.5

phpinfo() produced:

Configuration File (php.ini) Path   C:\WINDOWS
Loaded Configuration File   (none)

After unsuccessful testing most of the night with environment variables
including multiple reboots just to be sure, I finally broke down and
changed the registry value as recommended in the runtime configuration
section here: http://us3.php.net/configuration

Steps to reproduce:
1. Click Start -> Click Run -> Type Regedit -> Hit Enter
2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\PHP\
3. Right click in right-hand window pane and select New->String Value
4. Set Name to: IniFilePath
5. Set Data to: C:\Program Files\PHP\ (or wherever your installation
is)
6. Click Start -> Click Run -> Type cmd -> Hit Enter -> Type iisreset

phpinfo() now produces:

Configuration File (php.ini) Path   C:\WINDOWS
Loaded Configuration File   C:\Program Files\PHP\php.ini

Additionally, my mysql database is now working also.



[2008-04-13 17:20:35] thakralrohit at gmail dot com

I am having a similar problem. Have been trying to search on the web
for the whole day now but no success. I have this,
OS: Win XP Pro SP 2
IIS: 5.1
PHP: 5.2.5 (MSI Installer with MySQL)

Now, when I load phpinfo() I get output,
Configuration File (php.ini) Path   E:\WINDOWS
Loaded Configuration File   (none) 

No information about the three extensions that I have MySQL, MySQLi and
OpenSSL.

If I put the php.ini file in E:\WINDOWS directory nothing loads at
all.
I have tried re-installation, PHPRC environment variable setting and
Registry Settings but to no use. There is another setting further down
in the phpinfo() output,

extension_dir   C:\php5 

Can someone please help. It seems like similar to this bug with no
update.

Thanks in advance.

Regards
Rohit



[2008-04-05 19:02:54] caseyy at gmail dot com

I am also having this problem. phpinfo says config is being looked for
in my windows directory despite httpconf specifying the right
directory(C:\PHP). Problem is on Vista too. When I copy the ini file to
the windows directory, nothing loads at all, just a blank screen.



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/42849

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

#44846 [Fbk->Opn]: Missing MYSQLI_ENUM_FLAG

[marc at phpmyadmin dot net]

 ID:   44846
 User updated by:  marc at phpmyadmin dot net
 Reported By:  marc at phpmyadmin dot net
-Status:   Feedback
+Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux
 PHP Version:  5.2.6RC5
 Assigned To:  andrey
 New Comment:

Hello Andrey,
it's ok for just 5.3. A reference to this in the manual would be
appreciated.

Regards,
Marc


Previous Comments:


[2008-07-21 18:26:48] [EMAIL PROTECTED]

I see it in 5.3-dev

[EMAIL PROTECTED]:~/dev/vanilla/php5_3/ext/mysqli> grep ENUM *
mysqli.c:   REGISTER_LONG_CONSTANT("MYSQLI_ENUM_FLAG", ENUM_FLAG,
CONST_CS | CONST_PERSISTENT);

Do you want it in 5.2 ? I think there will be no more versions of 5.2




[2008-04-27 15:19:10] marc at phpmyadmin dot net

Description:

In ext/mysqli/mysqli.c, please add
REGISTER_LONG_CONSTANT("MYSQLI_ENUM_FLAG", ENUM_FLAG, CONST_CS |
CONST_PERSISTENT);

and also add a reference to MYSQLI_ENUM_FLAG in the PHP manual:
http://www.php.net/manual/en/mysqli.constants.php

The value of this ENUM_FLAG can be seen in the MySQL source:
mysql-5.0.51a/include/mysql_com.h

Reproduce code:
---
php.n






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

#45265 [NEW]: stripos() very slow

[marc at phpmyadmin dot net]

From: marc at phpmyadmin dot net
Operating system: Windows XP SP2
PHP version:  5.2.6
PHP Bug Type: Performance problem
Bug description:  stripos() very slow

Description:

stripos() is very slow on Windows, about ten times slower than on Linux. 

Reproduce code:
---
$a = str_repeat('x', 10);
for ($i = 0; $i < 1; $i++) {
$b = stripos($a, 'y');
}


Expected result:

On Linux it takes about 3 secondes.

Actual result:
--
On Windows: 30 seconds

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

#44846 [NEW]: Missing MYSQLI_ENUM_FLAG

[marc at phpmyadmin dot net]

From: marc at phpmyadmin dot net
Operating system: Linux
PHP version:  5.2.6RC5
PHP Bug Type: MySQLi related
Bug description:  Missing MYSQLI_ENUM_FLAG

Description:

In ext/mysqli/mysqli.c, please add
REGISTER_LONG_CONSTANT("MYSQLI_ENUM_FLAG", ENUM_FLAG, CONST_CS |
CONST_PERSISTENT);

and also add a reference to MYSQLI_ENUM_FLAG in the PHP manual:
http://www.php.net/manual/en/mysqli.constants.php

The value of this ENUM_FLAG can be seen in the MySQL source:
mysql-5.0.51a/include/mysql_com.h

Reproduce code:
---
php.n


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

#43536 [NEW]: Specifying a nameserver for DNS requests

[marc at perkel dot com]

From: marc at perkel dot com
Operating system: all
PHP version:  5.2.5
PHP Bug Type: Feature/Change Request
Bug description:  Specifying a nameserver for DNS requests

Description:

It would be nice if there were a way to direct DNS requests to a specific
nameserver so that one could write code that tests what a specific
nameserver is returning and avoid caching. That way if you are writing a
diagnostic tool to test name server configurations it will work correctly.
Would like to be able to write what DNSstuff does in PHP.



-- 
Edit bug report at http://bugs.php.net/?id=43536&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=43536&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=43536&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=43536&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=43536&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43536&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=43536&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=43536&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43536&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43536&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=43536&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43536&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=43536&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=43536&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43536&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=43536&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43536&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43536&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=43536&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=43536&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=43536&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43536&r=mysqlcfg

#42983 [Opn]: Regression: global variables get lost

[marc dot bau at gmx dot net]

 ID:   42983
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
 Status:   Open
 Bug Type: Variables related
 Operating System: WinXP & openSUSE 10.3
 PHP Version:  5.2.4
 New Comment:

I have reinstalled my 5.2.3 and replaced the directory with the ZIP
version and tested latest 5.2.5-dev... and it WORKS! So i'd like to know
- is there a list of bugs fixed until today so i can get an idea about
the bug?

The new openSuSE 10.3 final contains PHP 5.2.4 and is therefore
broken... i'd like to get this fixed, but i don't want to compile
myself! Maybe SuSE will provide a hotfix for this... i don't know - but
i think we should know which patch causes this bug and how heavy others
might depend on this... or we have a half year to wait for the next
openSUSE to get this fixed if they update their packages.


Previous Comments:


[2007-10-16 20:38:25] marc dot bau at gmx dot net

Thank you for the snapshot links. i tried the Windows installer package
and get:

"The installer has encountered an unexpected error installing this
package. This may indicate a problem with this package. The error code
is 2878".

And then setup closes.



[2007-10-16 11:24:22] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





[2007-10-16 10:54:31] crrodriguez at suse dot de

if evil^Wglobal variables gets lost, then there is definately a way to
shortly reproduce the problem, have you contacted drupal developers
about this problem ?

----

[2007-10-16 06:30:32] marc dot bau at gmx dot net

Sorry, you need the install package
drupal-5.2-yaml-for-drupal-5.x-3.0.3.7-2007092601.tar.gz

----

[2007-10-16 06:26:45] marc dot bau at gmx dot net

i have no idea what you need.

Install http://www.yaml-fuer-drupal.de/de/download
(yaml-for-drupal-5.x-3.0.3.7.tar.gz). Unpack and start install
./install.php, select YAML as Install profile and German as your
language. Try to stracktrace why $install_locale in
\profiles\yaml\yaml.profile gives nothing back.

global $install_locale;
if ($install_locale == 'de') {

or inside the _autolocale_install_po_files() function file
"sites\all\modules\autolocale\autolocale.install" the $install_locale is
no more filled with "de", too.

I have no idea how to repro this, but this code works with <=5.2.3 and
is broken with 5.2.4. If you don't like to repro try to look the PHP
source and find out what's wrong here... shouldn't be impossible to
find, while we know this is a regression introduced with 5.2.4



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/42983

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

#42983 [Fbk->Opn]: Regression: global variables get lost

[marc dot bau at gmx dot net]

 ID:   42983
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Variables related
 Operating System: WinXP & openSUSE 10.3
 PHP Version:  5.2.4
 New Comment:

Thank you for the snapshot links. i tried the Windows installer package
and get:

"The installer has encountered an unexpected error installing this
package. This may indicate a problem with this package. The error code
is 2878".

And then setup closes.


Previous Comments:


[2007-10-16 11:24:22] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





[2007-10-16 10:54:31] crrodriguez at suse dot de

if evil^Wglobal variables gets lost, then there is definately a way to
shortly reproduce the problem, have you contacted drupal developers
about this problem ?



[2007-10-16 06:30:32] marc dot bau at gmx dot net

Sorry, you need the install package
drupal-5.2-yaml-for-drupal-5.x-3.0.3.7-2007092601.tar.gz



[2007-10-16 06:26:45] marc dot bau at gmx dot net

i have no idea what you need.

Install http://www.yaml-fuer-drupal.de/de/download
(yaml-for-drupal-5.x-3.0.3.7.tar.gz). Unpack and start install
./install.php, select YAML as Install profile and German as your
language. Try to stracktrace why $install_locale in
\profiles\yaml\yaml.profile gives nothing back.

global $install_locale;
if ($install_locale == 'de') {

or inside the _autolocale_install_po_files() function file
"sites\all\modules\autolocale\autolocale.install" the $install_locale is
no more filled with "de", too.

I have no idea how to repro this, but this code works with <=5.2.3 and
is broken with 5.2.4. If you don't like to repro try to look the PHP
source and find out what's wrong here... shouldn't be impossible to
find, while we know this is a regression introduced with 5.2.4



[2007-10-15 22:11:02] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




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/42983

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

#42983 [Opn]: Regression: global variables get lost

[marc dot bau at gmx dot net]

 ID:   42983
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
 Status:   Open
 Bug Type: Variables related
 Operating System: WinXP & openSUSE 10.3
 PHP Version:  5.2.4
 New Comment:

Sorry, you need the install package
drupal-5.2-yaml-for-drupal-5.x-3.0.3.7-2007092601.tar.gz


Previous Comments:


[2007-10-16 06:26:45] marc dot bau at gmx dot net

i have no idea what you need.

Install http://www.yaml-fuer-drupal.de/de/download
(yaml-for-drupal-5.x-3.0.3.7.tar.gz). Unpack and start install
./install.php, select YAML as Install profile and German as your
language. Try to stracktrace why $install_locale in
\profiles\yaml\yaml.profile gives nothing back.

global $install_locale;
if ($install_locale == 'de') {

or inside the _autolocale_install_po_files() function file
"sites\all\modules\autolocale\autolocale.install" the $install_locale is
no more filled with "de", too.

I have no idea how to repro this, but this code works with <=5.2.3 and
is broken with 5.2.4. If you don't like to repro try to look the PHP
source and find out what's wrong here... shouldn't be impossible to
find, while we know this is a regression introduced with 5.2.4



[2007-10-15 22:11:02] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


----

[2007-10-15 21:49:33] marc dot bau at gmx dot net

Description:

Hi

i think i've struggled about a critical bug in 5.2.4 on Windows XP IIS
with ISAPI and openSUSE 10.3 with Apache 2.2.4. The "global" variables
looks simply lost. I've tried to install a
multilingual version of Drupal 5.2 and as i figured out the "global
$install_locale;" variable gets lost anywhere...

I have downgraded to PHP 5.2.1 re-testet (works) and upgraded back to
PHP 5.2.3 works, too.

Greetings
Marc

Reproduce code:
---
Install Drupal 5.2 with YAML for Drupal Complete package and you will
see the global var gets lost and drupal is not installed in a selected
language as it should.

I'm sorry i have no small and easy repro code...

Expected result:

not lost global variables

Actual result:
--
PHP 5.2.3 and 5.2.1 works well, 5.2.4 is broken





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

#42983 [Fbk->Opn]: Regression: global variables get lost

[marc dot bau at gmx dot net]

 ID:   42983
 User updated by:  marc dot bau at gmx dot net
-Summary:  global variables get lost
 Reported By:  marc dot bau at gmx dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Variables related
 Operating System: WinXP & openSUSE 10.3
 PHP Version:  5.2.4
 New Comment:

i have no idea what you need.

Install http://www.yaml-fuer-drupal.de/de/download
(yaml-for-drupal-5.x-3.0.3.7.tar.gz). Unpack and start install
./install.php, select YAML as Install profile and German as your
language. Try to stracktrace why $install_locale in
\profiles\yaml\yaml.profile gives nothing back.

global $install_locale;
if ($install_locale == 'de') {

or inside the _autolocale_install_po_files() function file
"sites\all\modules\autolocale\autolocale.install" the $install_locale is
no more filled with "de", too.

I have no idea how to repro this, but this code works with <=5.2.3 and
is broken with 5.2.4. If you don't like to repro try to look the PHP
source and find out what's wrong here... shouldn't be impossible to
find, while we know this is a regression introduced with 5.2.4


Previous Comments:


[2007-10-15 22:11:02] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


----

[2007-10-15 21:49:33] marc dot bau at gmx dot net

Description:

Hi

i think i've struggled about a critical bug in 5.2.4 on Windows XP IIS
with ISAPI and openSUSE 10.3 with Apache 2.2.4. The "global" variables
looks simply lost. I've tried to install a
multilingual version of Drupal 5.2 and as i figured out the "global
$install_locale;" variable gets lost anywhere...

I have downgraded to PHP 5.2.1 re-testet (works) and upgraded back to
PHP 5.2.3 works, too.

Greetings
Marc

Reproduce code:
---
Install Drupal 5.2 with YAML for Drupal Complete package and you will
see the global var gets lost and drupal is not installed in a selected
language as it should.

I'm sorry i have no small and easy repro code...

Expected result:

not lost global variables

Actual result:
--
PHP 5.2.3 and 5.2.1 works well, 5.2.4 is broken





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

#42983 [NEW]: global variables get lost

[marc dot bau at gmx dot net]

From: marc dot bau at gmx dot net
Operating system: WinXP & openSUSE 10.3
PHP version:  5.2.4
PHP Bug Type: Variables related
Bug description:  global variables get lost

Description:

Hi

i think i've struggled about a critical bug in 5.2.4 on Windows XP IIS
with ISAPI and openSUSE 10.3 with Apache 2.2.4. The "global" variables
looks simply lost. I've tried to install a
multilingual version of Drupal 5.2 and as i figured out the "global
$install_locale;" variable gets lost anywhere...

I have downgraded to PHP 5.2.1 re-testet (works) and upgraded back to
PHP 5.2.3 works, too.

Greetings
Marc

Reproduce code:
---
Install Drupal 5.2 with YAML for Drupal Complete package and you will see
the global var gets lost and drupal is not installed in a selected language
as it should.

I'm sorry i have no small and easy repro code...

Expected result:

not lost global variables

Actual result:
--
PHP 5.2.3 and 5.2.1 works well, 5.2.4 is broken

-- 
Edit bug report at http://bugs.php.net/?id=42983&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=42983&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=42983&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=42983&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42983&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=42983&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=42983&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42983&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42983&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=42983&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42983&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=42983&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=42983&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42983&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=42983&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42983&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42983&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=42983&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=42983&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=42983&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42983&r=mysqlcfg

#42277 [Com]: bug in processing commentary

[marc dot bau at gmx dot net]

 ID:   42277
 Comment by:   marc dot bau at gmx dot net
 Reported By:  partyspb at yandex dot ru
 Status:   No Feedback
 Bug Type: *General Issues
 Operating System: FreeBSD 6.1-RELEASE
 PHP Version:  5.2.4RC1
 New Comment:

Hi

i think i've got the same problem with 5.2.4 on Windows with IIS and
ISAPI. "global" variables looks simply lost. I've tried to install a
multilingual version of Drupal 5.2 and as i figured out the "global
$install_locale;" variable gets lost anywhere...

I have downgraded to PHP 5.2.1 re-testet (works) and upgraded back to
PHP 5.2.3 works, too.

Greetings
Marc


Previous Comments:


[2007-08-20 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2007-08-12 13:51:00] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


.



[2007-08-12 13:30:21] partyspb at yandex dot ru

Description:

PHP 5.2.3

bug in processing commentary

code:
$my_var='1';
function my_fun() 
{//my text (I use russian) 
GLOBAL $my_var;
$var=$my_var;
echo $var;
} 
my_fun();

return: Notice: Undefined variable: $my_var ...

(don't job "GLOBAL") but if replace //my text   to   /* my text */

return: 1






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

#42977 [NEW]: localhost setting goes to socket instead of 127.0.0.1

[marc at perkel dot com]

From: marc at perkel dot com
Operating system: linux
PHP version:  5.2.4
PHP Bug Type: MySQL related
Bug description:  localhost setting goes to socket instead of 127.0.0.1

Description:

When a PHP application tries to call MySQL and it is set to talk to
localhost it talks only to the socket and not to TCP 127.0.0.1. In my.cnt I
set the client as follows:

[client]
protocol=TCP

However that is ignored.

I'm running a web server hosting some 100 applications installed by many
different people. So changing all the localhost setting to 127.0.0.1 isn't
practical. What I want to do is not use the socket at
/var/lib/mysql/mysql.sock at all. The reason is that I'm trying to mugrate
all mysql to a dedicated mysql server and having the web server talk to
127.0.0.1 and link them with an SSH tunnel. In this setup there will be no
socket.

I left a bug report at mysql.com and they blame the problem on PHP so i'm
now here to let you know about it.


Reproduce code:
---
Set configuration to localhost and disable socket and PHP can't talk to
TCP 127.0.0.1


Expected result:

I expect PHP to ignore the unix socket and talk to TCP 127.0.0.1

Actual result:
--
No access

-- 
Edit bug report at http://bugs.php.net/?id=42977&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=42977&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=42977&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=42977&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42977&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=42977&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=42977&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42977&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42977&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=42977&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42977&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=42977&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=42977&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42977&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=42977&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42977&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42977&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=42977&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=42977&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=42977&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42977&r=mysqlcfg

#41985 [Opn]: rename doesn't work

[marc dot bau at gmx dot net]

 ID:   41985
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows
 PHP Version:  5.2.3
 New Comment:

Well, if this rename is not possible atomically (how bad this ever is),
i think PHP should handle the copy/unlink logic in background if i use
"rename()".

I simply don't like to think about possible platform dependencies (i
don't know anything about) and hack around in a bad way that additional
produce an error with "E_ALL & ~E_NOTICE" i cannot circumvent.


Previous Comments:


[2007-07-14 10:35:16] [EMAIL PROTECTED]

I actually agree with that... however, it's not possible to do this
atomically on windows if the file you're moving to exists. The only
option is to unlink() the target and then do the rename() but that
leaves a race condition. I don't think that is solvable on Windows.

----

[2007-07-13 20:57:49] marc dot bau at gmx dot net

Do you know how this works on *nix systems?

Well i will tell you - it will *move* the "new file" over the "old
file" in an atomic rename. This is what PHP needs to handle on Windows,
too. I don't need any extras on *nix to rename. And PHP internal command
should work platform independent. 

This bug should be fixed to make sure the code runs on windows in the
*same way* as it does on *nix systems.

What is so difficult to understand about this? Writing write code once,
*run everywhere* is not possible with this bug.



[2007-07-13 20:48:09] [EMAIL PROTECTED]

Please open a dictionary and translate the error message:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

It says FILE EXISTS, don't you see it?
Please do NOT reopen the report again.
Thank you.

----

[2007-07-13 20:36:36] marc dot bau at gmx dot net

As already said, this won't help anything.

DON'T WORK:


Error:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

DON'T WORK:


Error:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

DON'T WORK:


Error:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

DON'T WORK:


Error:
PHP Warning:  rename(C:/temp/tmp_file.txt.new,C:/temp/tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2


So you have a Windows Box next to you? Before answering, test yourself
if you don't trust me, but don't close this case until this bug has been
fixed! THX.



[2007-07-13 18:44:15] [EMAIL PROTECTED]

Please escape the \ as advised in the manual.



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/41985

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

#41985 [Bgs->Opn]: rename doesn't work

[marc dot bau at gmx dot net]

 ID:   41985
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
-Status:   Bogus
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows
 PHP Version:  5.2.3
 New Comment:

Do you know how this works on *nix systems?

Well i will tell you - it will *move* the "new file" over the "old
file" in an atomic rename. This is what PHP needs to handle on Windows,
too. I don't need any extras on *nix to rename. And PHP internal command
should work platform independent. 

This bug should be fixed to make sure the code runs on windows in the
*same way* as it does on *nix systems.

What is so difficult to understand about this? Writing write code once,
*run everywhere* is not possible with this bug.


Previous Comments:


[2007-07-13 20:48:09] [EMAIL PROTECTED]

Please open a dictionary and translate the error message:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

It says FILE EXISTS, don't you see it?
Please do NOT reopen the report again.
Thank you.

----

[2007-07-13 20:36:36] marc dot bau at gmx dot net

As already said, this won't help anything.

DON'T WORK:


Error:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

DON'T WORK:


Error:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

DON'T WORK:


Error:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

DON'T WORK:


Error:
PHP Warning:  rename(C:/temp/tmp_file.txt.new,C:/temp/tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2


So you have a Windows Box next to you? Before answering, test yourself
if you don't trust me, but don't close this case until this bug has been
fixed! THX.



[2007-07-13 18:44:15] [EMAIL PROTECTED]

Please escape the \ as advised in the manual.

----

[2007-07-13 18:33:37] marc dot bau at gmx dot net

This doesn't have anything to do with double quotes. With single quotes
this isn't working, too.





[2007-07-13 09:30:47] [EMAIL PROTECTED]

http://www.php.net/manual/en/language.types.string.php#language.types.string.syntax.double



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/41985

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

#41985 [Bgs->Opn]: rename doesn't work

[marc dot bau at gmx dot net]

 ID:   41985
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
-Status:   Bogus
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows
 PHP Version:  5.2.3
 New Comment:

As already said, this won't help anything.

DON'T WORK:


Error:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

DON'T WORK:


Error:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

DON'T WORK:


Error:
PHP Warning:  rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2

DON'T WORK:


Error:
PHP Warning:  rename(C:/temp/tmp_file.txt.new,C:/temp/tmp_file.txt):
File exists in C:\Temp\rename-test.php on line 2


So you have a Windows Box next to you? Before answering, test yourself
if you don't trust me, but don't close this case until this bug has been
fixed! THX.


Previous Comments:


[2007-07-13 18:44:15] [EMAIL PROTECTED]

Please escape the \ as advised in the manual.

----

[2007-07-13 18:33:37] marc dot bau at gmx dot net

This doesn't have anything to do with double quotes. With single quotes
this isn't working, too.





[2007-07-13 09:30:47] [EMAIL PROTECTED]

http://www.php.net/manual/en/language.types.string.php#language.types.string.syntax.double

----

[2007-07-13 06:12:45] marc dot bau at gmx dot net

What are you talking about? Writing write code once, run everywhere?
This is currently not possible and therefor this is for sure a bug.

Rename is not working the same way on all OS'es and this is why i filed
this bug. I don't like to workaround in a shit way like described in
http://us.php.net/manual/en/function.rename.php#56576. This one produces
a PHP error that is logged in my CMS.

So let's fix this to make PHP work in the same way on all OS without
dirty hacks. You may fix this in the way of #56576 PHP *internally*, but
don't make me to hack around outside and create crappy code around.



[2007-07-12 22:50:59] [EMAIL PROTECTED]

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

\\t has a special meaning in strings with double quotes.



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/41985

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

#41985 [Bgs->Opn]: rename doesn't work

[marc dot bau at gmx dot net]

 ID:   41985
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
-Status:   Bogus
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows
 PHP Version:  5.2.3
 New Comment:

This doesn't have anything to do with double quotes. With single quotes
this isn't working, too.




Previous Comments:


[2007-07-13 09:30:47] [EMAIL PROTECTED]

http://www.php.net/manual/en/language.types.string.php#language.types.string.syntax.double



[2007-07-13 06:12:45] marc dot bau at gmx dot net

What are you talking about? Writing write code once, run everywhere?
This is currently not possible and therefor this is for sure a bug.

Rename is not working the same way on all OS'es and this is why i filed
this bug. I don't like to workaround in a shit way like described in
http://us.php.net/manual/en/function.rename.php#56576. This one produces
a PHP error that is logged in my CMS.

So let's fix this to make PHP work in the same way on all OS without
dirty hacks. You may fix this in the way of #56576 PHP *internally*, but
don't make me to hack around outside and create crappy code around.



[2007-07-12 22:50:59] [EMAIL PROTECTED]

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

\\t has a special meaning in strings with double quotes.

----

[2007-07-12 22:26:51] marc dot bau at gmx dot net

Description:

The "rename" in PHP doesn't work as expected on Windows.

Reproduce code:
---


Expected result:

successful rename completed.

Actual result:
--
1. rename isn't working
2. C:\temp\tmp_file.txt is not replaced with C:\temp\tmp_file.txt.new
3. C:\temp\tmp_file.txt.new not moved to C:\temp\tmp_file.txt





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

#41985 [Bgs->Opn]: rename doesn't work

[marc dot bau at gmx dot net]

 ID:   41985
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
-Status:   Bogus
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows
 PHP Version:  5.2.3
 New Comment:

What are you talking about? Writing write code once, run everywhere?
This is currently not possible and therefor this is for sure a bug.

Rename is not working the same way on all OS'es and this is why i filed
this bug. I don't like to workaround in a shit way like described in
http://us.php.net/manual/en/function.rename.php#56576. This one produces
a PHP error that is logged in my CMS.

So let's fix this to make PHP work in the same way on all OS without
dirty hacks. You may fix this in the way of #56576 PHP *internally*, but
don't make me to hack around outside and create crappy code around.


Previous Comments:


[2007-07-12 22:50:59] [EMAIL PROTECTED]

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

\\t has a special meaning in strings with double quotes.



[2007-07-12 22:26:51] marc dot bau at gmx dot net

Description:

The "rename" in PHP doesn't work as expected on Windows.

Reproduce code:
---


Expected result:

successful rename completed.

Actual result:
--
1. rename isn't working
2. C:\temp\tmp_file.txt is not replaced with C:\temp\tmp_file.txt.new
3. C:\temp\tmp_file.txt.new not moved to C:\temp\tmp_file.txt





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

#41985 [NEW]: rename doesn't work

[marc dot bau at gmx dot net]

From: marc dot bau at gmx dot net
Operating system: Windows
PHP version:  5.2.3
PHP Bug Type: Filesystem function related
Bug description:  rename doesn't work

Description:

The "rename" in PHP doesn't work as expected on Windows.

Reproduce code:
---


Expected result:

successful rename completed.

Actual result:
--
1. rename isn't working
2. C:\temp\tmp_file.txt is not replaced with C:\temp\tmp_file.txt.new
3. C:\temp\tmp_file.txt.new not moved to C:\temp\tmp_file.txt

-- 
Edit bug report at http://bugs.php.net/?id=41985&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41985&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41985&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41985&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41985&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41985&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41985&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41985&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41985&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41985&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41985&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41985&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41985&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41985&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41985&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41985&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41985&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41985&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41985&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41985&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41985&r=mysqlcfg

#41177 [NEW]: Split, search doesn't split with dots.

[marc at thewebmen dot com]

From: marc at thewebmen dot com
Operating system: 
PHP version:  5.2.1
PHP Bug Type: *General Issues
Bug description:  Split, search doesn't split with dots.

Description:

Split, search doesn't split with dots.

Reproduce code:
---
$aa = split('.', $ccc);


Expected result:

one array splitted by dots

Actual result:
--
10 field array ???

-- 
Edit bug report at http://bugs.php.net/?id=41177&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41177&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41177&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41177&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41177&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41177&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41177&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41177&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41177&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41177&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41177&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41177&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41177&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41177&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41177&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41177&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41177&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41177&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41177&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41177&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41177&r=mysqlcfg

#41001 [NEW]: magic_qoutes_gpc off, but still adding slashes

[marc at bhosted dot nl]

From: marc at bhosted dot nl
Operating system: Linux version 2.4.21
PHP version:  5.2.1
PHP Bug Type: PHP options/info functions
Bug description:  magic_qoutes_gpc off, but still adding slashes

Description:

Using:
htscanner 0.8.1
PHP 5.2.1 as CGI (suphp).

Setting magic_quotes_gpc to off using .htaccess. phpinfo reports 
magic_quotes_gpc local is off, master is still on. Testing this with a
$_GET results in the slash still added


-- 
Edit bug report at http://bugs.php.net/?id=41001&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41001&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41001&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41001&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41001&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41001&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41001&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41001&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41001&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41001&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41001&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41001&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41001&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41001&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41001&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41001&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41001&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41001&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41001&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41001&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41001&r=mysqlcfg

#41001 [Opn]: magic_qoutes_gpc off, but still adding slashes

[marc at bhosted dot nl]

 ID:   41001
 User updated by:  marc at bhosted dot nl
 Reported By:  marc at bhosted dot nl
 Status:   Open
 Bug Type: PHP options/info functions
 Operating System: Linux version 2.4.21
 PHP Version:  5.2.1
 New Comment:

A little more information:

URL example: http://localhost/phpinfo.php?test=test'test

.htaccess:

php_flag magic_quotes_gpc off


phpinfo.php Source:


Result:
test\'test




Previous Comments:


[2007-04-05 08:38:50] marc at bhosted dot nl

Description:

Using:
htscanner 0.8.1
PHP 5.2.1 as CGI (suphp).

Setting magic_quotes_gpc to off using .htaccess. phpinfo reports 
magic_quotes_gpc local is off, master is still on. Testing this with a
$_GET results in the slash still added






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

#39984 [Sus]: Response header sent as 302 despite being set to 301

[marc dot bau at gmx dot net]

 ID:   39984
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
 Status:   Suspended
 Bug Type: IIS related
 Operating System: WinXP
 PHP Version:  5.2.1
 Assigned To:  edink
 New Comment:

And this comes to me with FastCGI from the URL you provided. Wrong in a
different way - and buggy again. Any way to get this bug really fixed?


HTTP/1.x 301 OK
Server: Microsoft-IIS/5.1
Date: Fri, 23 Feb 2007 14:04:43 GMT
X-Powered-By: ASP.NET, PHP/5.2.1
Connection: close
Location: http://www.example.com
Content-Type: text/html


Previous Comments:


[2007-02-23 13:41:11] marc dot bau at gmx dot net

Have a look to this headers. "Undescribed" is are wrong, too. I tryed
to use "php5isapi.dll" for PHP extension.


GET /test.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1)
Gecko/20061204 Firefox/2.0.0.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=nihrgij25siffg5r9dbr17boq5

HTTP/1.x 301 Undescribed
Server: Microsoft-IIS/5.1
Date: Fri, 23 Feb 2007 13:38:19 GMT
X-Powered-By: ASP.NET, PHP/5.2.1
Connection: close
Location: http://www.example.com
Content-Type: text/html



[2007-02-23 13:28:44] marc dot bau at gmx dot net

i wonder why there shouldn't be a way to handle this. 

As one example ActiveState (www.activestate.com) Perl have a CGI
version and this works well, too. You should spend some time on the
Perl Code, maybe there is a small trick inside.



[2007-02-19 23:23:06] [EMAIL PROTECTED]

Seems that there is no way a CGI script can convince IIS to output
something else than 302 response if you have location header.

Same IIS using Microsofts latest FCGI isapi has no problems with PHP
outputing correct status code.

I recommend that you switch to that instead of using raw cgi, the
perfomance icrease is dramatic as well.

http://www.iis.net/default.aspx?tabid=151


----

[2007-02-18 12:05:02] marc dot bau at gmx dot net

Additional to this a header('HTTP/1.0 404 Not Found') produces a "404
OK".



[2007-01-11 10:02:47] [EMAIL PROTECTED]

Edin, could you plz verify if this problem is still valid?



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/39984

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

#39984 [Sus]: Response header sent as 302 despite being set to 301

[marc dot bau at gmx dot net]

 ID:   39984
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
 Status:   Suspended
 Bug Type: IIS related
 Operating System: WinXP
 PHP Version:  5.2.1
 Assigned To:  edink
 New Comment:

Have a look to this headers. "Undescribed" is are wrong, too. I tryed
to use "php5isapi.dll" for PHP extension.


GET /test.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1)
Gecko/20061204 Firefox/2.0.0.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=nihrgij25siffg5r9dbr17boq5

HTTP/1.x 301 Undescribed
Server: Microsoft-IIS/5.1
Date: Fri, 23 Feb 2007 13:38:19 GMT
X-Powered-By: ASP.NET, PHP/5.2.1
Connection: close
Location: http://www.example.com
Content-Type: text/html


Previous Comments:


[2007-02-23 13:28:44] marc dot bau at gmx dot net

i wonder why there shouldn't be a way to handle this. 

As one example ActiveState (www.activestate.com) Perl have a CGI
version and this works well, too. You should spend some time on the
Perl Code, maybe there is a small trick inside.



[2007-02-19 23:23:06] [EMAIL PROTECTED]

Seems that there is no way a CGI script can convince IIS to output
something else than 302 response if you have location header.

Same IIS using Microsofts latest FCGI isapi has no problems with PHP
outputing correct status code.

I recommend that you switch to that instead of using raw cgi, the
perfomance icrease is dramatic as well.

http://www.iis.net/default.aspx?tabid=151


----

[2007-02-18 12:05:02] marc dot bau at gmx dot net

Additional to this a header('HTTP/1.0 404 Not Found') produces a "404
OK".



[2007-01-11 10:02:47] [EMAIL PROTECTED]

Edin, could you plz verify if this problem is still valid?

----

[2007-01-04 22:14:28] marc dot bau at gmx dot net

open



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/39984

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

#39984 [Sus]: Response header sent as 302 despite being set to 301

[marc dot bau at gmx dot net]

 ID:   39984
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
 Status:   Suspended
 Bug Type: IIS related
 Operating System: WinXP
 PHP Version:  5.2.1
 Assigned To:  edink
 New Comment:

i wonder why there shouldn't be a way to handle this. 

As one example ActiveState (www.activestate.com) Perl have a CGI
version and this works well, too. You should spend some time on the
Perl Code, maybe there is a small trick inside.


Previous Comments:


[2007-02-19 23:23:06] [EMAIL PROTECTED]

Seems that there is no way a CGI script can convince IIS to output
something else than 302 response if you have location header.

Same IIS using Microsofts latest FCGI isapi has no problems with PHP
outputing correct status code.

I recommend that you switch to that instead of using raw cgi, the
perfomance icrease is dramatic as well.

http://www.iis.net/default.aspx?tabid=151




[2007-02-18 12:05:02] marc dot bau at gmx dot net

Additional to this a header('HTTP/1.0 404 Not Found') produces a "404
OK".



[2007-01-11 10:02:47] [EMAIL PROTECTED]

Edin, could you plz verify if this problem is still valid?

----

[2007-01-04 22:14:28] marc dot bau at gmx dot net

open

----

[2007-01-01 17:03:04] marc dot bau at gmx dot net

If Perl, ColdFusion and ASP Pages are correct and PHP not, what do you
think is wrong?

I think PHP! Maybe there is something wrong in the way how the status
is set or how the status is transfered to IIS... i don't know if there
is something special in IIS, but it looks like a PHP Bug, while all
other script languages are correct.



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/39984

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

#39984 [Asn]: Response header sent as 302 despite being set to 301

[marc dot bau at gmx dot net]

 ID:   39984
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
 Status:   Assigned
 Bug Type: IIS related
 Operating System: WinXP
-PHP Version:  5.2.0
+PHP Version:  5.2.1
 Assigned To:  edink
 New Comment:

Additional to this a header('HTTP/1.0 404 Not Found') produces a "404
OK".


Previous Comments:


[2007-01-11 10:02:47] [EMAIL PROTECTED]

Edin, could you plz verify if this problem is still valid?



[2007-01-04 22:14:28] marc dot bau at gmx dot net

open



[2007-01-01 17:03:04] marc dot bau at gmx dot net

If Perl, ColdFusion and ASP Pages are correct and PHP not, what do you
think is wrong?

I think PHP! Maybe there is something wrong in the way how the status
is set or how the status is transfered to IIS... i don't know if there
is something special in IIS, but it looks like a PHP Bug, while all
other script languages are correct.



[2007-01-01 16:53:35] [EMAIL PROTECTED]

>From the PHP end of things the issue is resolved, if IIS does 
not properly handle the Status header in the event of 
redirects, that's hardly a PHP problem, no?

----

[2007-01-01 16:50:41] marc dot bau at gmx dot net

But this won't help me anything if you tell me it should be fixed and
it isn't. You should test this on IIS, while it is not working as
expected and i cannot fix this myself. 

So - this problem is OPEN until the bug is really fixed. I don't know
why your are closing it until it is working.



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/39984

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

#39984 [Csd->Opn]: Response header sent as 302 despite being set to 301

[marc dot bau at gmx dot net]

 ID:   39984
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
-Status:   Closed
+Status:   Open
 Bug Type: IIS related
 Operating System: WinXP
 PHP Version:  5.2.0
 New Comment:

open


Previous Comments:


[2007-01-01 17:03:04] marc dot bau at gmx dot net

If Perl, ColdFusion and ASP Pages are correct and PHP not, what do you
think is wrong?

I think PHP! Maybe there is something wrong in the way how the status
is set or how the status is transfered to IIS... i don't know if there
is something special in IIS, but it looks like a PHP Bug, while all
other script languages are correct.



[2007-01-01 16:53:35] [EMAIL PROTECTED]

>From the PHP end of things the issue is resolved, if IIS does 
not properly handle the Status header in the event of 
redirects, that's hardly a PHP problem, no?



[2007-01-01 16:50:41] marc dot bau at gmx dot net

But this won't help me anything if you tell me it should be fixed and
it isn't. You should test this on IIS, while it is not working as
expected and i cannot fix this myself. 

So - this problem is OPEN until the bug is really fixed. I don't know
why your are closing it until it is working.



[2007-01-01 16:32:16] [EMAIL PROTECTED]

Then it is probably due to IIS overwriting the Status code. 
Based on the current code in the CVS right now PHP sends the 
redirect code set by your application.



[2007-01-01 16:22:47] marc dot bau at gmx dot net

But i have used the Snapshot php5.2-win32-200701010730 !?



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/39984

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

#39984 [Csd]: Response header sent as 302 despite being set to 301

[marc dot bau at gmx dot net]

 ID:   39984
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
 Status:   Closed
 Bug Type: IIS related
 Operating System: WinXP
 PHP Version:  5.2.0
 New Comment:

If Perl, ColdFusion and ASP Pages are correct and PHP not, what do you
think is wrong?

I think PHP! Maybe there is something wrong in the way how the status
is set or how the status is transfered to IIS... i don't know if there
is something special in IIS, but it looks like a PHP Bug, while all
other script languages are correct.


Previous Comments:


[2007-01-01 16:53:35] [EMAIL PROTECTED]

>From the PHP end of things the issue is resolved, if IIS does 
not properly handle the Status header in the event of 
redirects, that's hardly a PHP problem, no?



[2007-01-01 16:50:41] marc dot bau at gmx dot net

But this won't help me anything if you tell me it should be fixed and
it isn't. You should test this on IIS, while it is not working as
expected and i cannot fix this myself. 

So - this problem is OPEN until the bug is really fixed. I don't know
why your are closing it until it is working.



[2007-01-01 16:32:16] [EMAIL PROTECTED]

Then it is probably due to IIS overwriting the Status code. 
Based on the current code in the CVS right now PHP sends the 
redirect code set by your application.



[2007-01-01 16:22:47] marc dot bau at gmx dot net

But i have used the Snapshot php5.2-win32-200701010730 !?



[2007-01-01 16:17:05] [EMAIL PROTECTED]

you need to use the 5.2 CVS snapshot



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39984

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

#39984 [Csd]: Response header sent as 302 despite being set to 301

[marc dot bau at gmx dot net]

 ID:   39984
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
 Status:   Closed
 Bug Type: IIS related
 Operating System: WinXP
 PHP Version:  5.2.0
 New Comment:

But this won't help me anything if you tell me it should be fixed and
it isn't. You should test this on IIS, while it is not working as
expected and i cannot fix this myself. 

So - this problem is OPEN until the bug is really fixed. I don't know
why your are closing it until it is working.


Previous Comments:


[2007-01-01 16:32:16] [EMAIL PROTECTED]

Then it is probably due to IIS overwriting the Status code. 
Based on the current code in the CVS right now PHP sends the 
redirect code set by your application.



[2007-01-01 16:22:47] marc dot bau at gmx dot net

But i have used the Snapshot php5.2-win32-200701010730 !?



[2007-01-01 16:17:05] [EMAIL PROTECTED]

you need to use the 5.2 CVS snapshot



[2007-01-01 11:49:00] marc dot bau at gmx dot net

same with php6.0-win32-200701010930:

HTTP/1.x 302 Object Moved
Server: Microsoft-IIS/5.1
Date: Mon, 01 Jan 2007 11:47:42 GMT
Connection: close
Content-Type: text/html
X-Powered-By: PHP/6.0.0-dev
Location: http://www.example.com



[2007-01-01 11:28:37] marc dot bau at gmx dot net

i'm sorry but i must reopen the case. i tested with snapshot
php5.2-win32-200701010730 and i got this:

Isn't this the CVS Version you talked about?


HTTP/1.x 302 Object Moved
Server: Microsoft-IIS/5.1
Date: Mon, 01 Jan 2007 11:26:59 GMT
Connection: close
Content-Type: text/html
X-Powered-By: PHP/5.2.1RC2-dev
Location: http://www.example.com



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/39984

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

#39984 [Fbk->Opn]: Response header sent as 302 despite being set to 301

[marc dot bau at gmx dot net]

 ID:   39984
 User updated by:  marc dot bau at gmx dot net
 Reported By:  marc dot bau at gmx dot net
-Status:   Feedback
+Status:   Open
 Bug Type: IIS related
 Operating System: WinXP
 PHP Version:  5.2.0
 New Comment:

But i have used the Snapshot php5.2-win32-200701010730 !?


Previous Comments:


[2007-01-01 16:17:05] [EMAIL PROTECTED]

you need to use the 5.2 CVS snapshot



[2007-01-01 11:49:00] marc dot bau at gmx dot net

same with php6.0-win32-200701010930:

HTTP/1.x 302 Object Moved
Server: Microsoft-IIS/5.1
Date: Mon, 01 Jan 2007 11:47:42 GMT
Connection: close
Content-Type: text/html
X-Powered-By: PHP/6.0.0-dev
Location: http://www.example.com



[2007-01-01 11:28:37] marc dot bau at gmx dot net

i'm sorry but i must reopen the case. i tested with snapshot
php5.2-win32-200701010730 and i got this:

Isn't this the CVS Version you talked about?


HTTP/1.x 302 Object Moved
Server: Microsoft-IIS/5.1
Date: Mon, 01 Jan 2007 11:26:59 GMT
Connection: close
Content-Type: text/html
X-Powered-By: PHP/5.2.1RC2-dev
Location: http://www.example.com



[2007-01-01 11:12:18] marc dot bau at gmx dot net

Thank you. I will test the latest Snapshot.

Are you able to backport this bugfix? I think this is very important
and critical bug for older versions, too.



[2006-12-31 19:22:24] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





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/39984

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