Bug #52298 [Com]: Apache service won't start with PHP enabled

[iajay at yahoo dot com]

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

 ID: 52298
 Comment by: iajay at yahoo dot com
 Reported by:murray at math dot umass dot edu
 Summary:Apache service won't start with PHP enabled
 Status: Not a bug
 Type:   Bug
 Package:Apache2 related
 Operating System:   Windows XP Pro (SP3)
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 New Comment:

This did not solve my problem. Apache didn't start even after doing this.
1. Comment out the PHPIniDir line in the httpd.conf file.
2. Include the full path in the LoadModule line. In my case, I am using 
Apache2.2 and my PHP directory is C:\PHP so my entry looked like this:

LoadModule php5_module "C:/php/php5apache2_2.dll"
 I got the error " Apache server encountered an error and needs to close"


Previous Comments:

[2011-08-04 21:57:43] jb at newsoftwaregroup dot com

I found it to be modules in the PHP.INI file.  Take them all out and see if 
Apache starts, then add them back and find culprit.


[2011-06-04 02:01:13] brianjameson1003 at gmail dot com

If this is a Windows 7 issue, I found a fix after much banging my head into the 
desk!

The person who said this was close, but it didn't work for me:


I figured it out by reading some other posts.  It may be Windows 7 only thing.  
I 
had to manually edit the httpd.conf file under Apache to point PHPIniDir to the 
PHP location.  It seems to be working fine on another 2003 server without 
having 
to do this manually. 

PHPIniDir "C:/Program Files/PHP/"



Here is what did work:
1. Comment out the PHPIniDir line in the httpd.conf file.
2. Include the full path in the LoadModule line. In my case, I am using 
Apache2.2 and my PHP directory is C:\PHP so my entry looked like this:

LoadModule php5_module "C:/php/php5apache2_2.dll"

Once I did that, Apache fired up with no problem and if you open the Apache 
Monitor, you can confirm that PHP is running. At the bottom it says: 
Apache/2.2.19(Win32)PHP/5.2.17


Hope that helps many of you out!


[2011-02-24 19:58:57] cyue at datalogics dot com

I figured it out by reading some other posts.  It may be Windows 7 only thing.  
I 
had to manually edit the httpd.conf file under Apache to point PHPIniDir to the 
PHP location.  It seems to be working fine on another 2003 server without 
having 
to do this manually. 

PHPIniDir "C:/Program Files/PHP/"


[2011-02-24 18:22:12] cyue at datalogics dot com

I am having the same problem. I installed Apache 2.2 and PHP 5.3.5 VC6 threaded 
version, Windows 7 64-bit system.  The Apache service can start without PHP 
installed, but after the PHP is installed, I am getting the error that the 
php5apache2_2.dll is not found error.  Even though it is inside the PHP folder.

Any suggestions?


[2010-07-21 22:51:22] m...@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.






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


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

Bug #65632 [Opn->Nab]: php ( CLI ) - 5-6 seconds execution time.

[laruence]

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

 ID: 65632
 Updated by: larue...@php.net
 Reported by:saleh at va dot com dot sa
 Summary:php ( CLI ) - 5-6 seconds execution time.
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS X86_64
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

close


Previous Comments:

[2013-09-08 18:35:28] saleh at va dot com dot sa

problem FIXED by adding:

MyIP MyHostname

to: /etc/hosts

now the cli is working as usual.


[2013-09-08 18:32:15] saleh at va dot com dot sa

why is it connecting to my DNS server !

31769 20:37:22.164603 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3 
<0.30>
31769 20:37:22.164710 connect(3, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.1.3")}, 16) = 0 <0.30> 
31769 20:37:22.164824 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, 
revents=POLLOUT}]) <0.26>
31769 20:37:22.164925 sendto(3, 
"wh\1\0\0\1\0\0\0\0\0\0\3lan\2va\3com\2sa\0\0\1\0\1", 31, MSG_NOSIGNAL, NULL, 
0) 
= 31 <0.37>
31769 20:37:22.165035 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 
([{fd=3, revents=POLLOUT}]) <0.24>  
31769 20:37:22.165132 sendto(3, 
"\314\33\1\0\0\1\0\0\0\0\0\0\3lan\2va\3com\2sa\0\0\34\0\1", 31, MSG_NOSIGNAL, 
NULL, 0) = 31 <0.32>
31769 20:37:22.165247 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 ([{fd=3, 
revents=POLLIN}]) <0.000659>
31769 20:37:22.165991 ioctl(3, FIONREAD, [47]) = 0 <0.27>
31769 20:37:22.166092 recvfrom(3, 
"wh\201\0\0\1\0\1\0\0\0\0\3lan\2va\3com\2sa\0\0\1\0\1\300"..., 2048, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=i$
31769 20:37:22.166271 poll([{fd=3, events=POLLIN}], 1, 4998) = 1 ([{fd=3, 
revents=POLLIN}]) <3.723296>


[2013-09-08 17:45:05] saleh at va dot com dot sa

http://vaiasa.com/out.txt

looks like php is trying to include libs that is not there!

note i compiled with -with-libdir=lib64
and all the required libs installed and php did not complie that its not found.


[2013-09-08 05:45:57] ras...@php.net

That doesn't sound right. I see no such delay on Centos here. Could you please 
run this:

strace -Ff -tt -T -o out.txt php hello.php

And put out.txt somewhere we can see it? (it's going to be too long to paste 
into 
the bug report)


[2013-09-08 01:41:05] saleh at va dot com dot sa

Description:

there is an execution delay ( 5 seconds ) when running PHP from the command 
line.
however this thing dose not happen on the Apache module.

PHP: 5.5.3 (latest)
OS: CentOS x86_64
Compile command:

Configure Command =>  './configure'  '--with-apxs2' '--with-openssl' '--with-
pcre-regex' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--
with-curl' '--enable-exif' '--enable-ftp' '--with-gd' '--with-vpx-dir' '--with-
jpeg-dir' '--with-png-dir' '--with-xpm-dir' '--with-freetype-dir' 
'--with-t1lib' 
'--enable-gd-native-ttf' '--with-gettext' '--with-mhash' '--with-imap' '--with-
kerberos' '--with-imap-ssl' '--enable-intl' '--with-ldap' '--with-ldap-sasl' '--
enable-mbstring' '--with-mcrypt' '--with-mysql' '--with-mysqli' '--with-
unixODBC=/usr' '--enable-pcntl' '--with-pdo-mysql' '--with-libedit' '--with-
readline' '--enable-shmop' '--with-libxml-dir' '--with-snmp' '--enable-soap' '--
enable-sockets' '--with-tidy' '--enable-wddx' '--with-xmlrpc' 
'--with-iconv-dir' 
'--with-xsl' '--enable-zip' '--with-zlib-dir' '--with-pcre-dir' '--with-pear' '-
-with-libdir=lib64' '--enable-opcache=no'


Test script:
---


or just runing `php -v`

Expected result:

less than 1 secound execution time

Actual result:
--
5 seconds execution time






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

Bug #64755 [Com]: Only variables should be passed by reference

[guy at syntheticwebapps dot com]

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

 ID: 64755
 Comment by: guy at syntheticwebapps dot com
 Reported by:eth at ethaniel dot com
 Summary:Only variables should be passed by reference
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian 7.0
 PHP Version:5.4.14
 Block user comment: N
 Private report: N

 New Comment:

To respond to eth: I'm not disagreeing with you, but just keep in mind that 
before 5.4, func()[$index] was not legal syntax, so it made a lot of sense to 
use phrasing like array_shift(array_splice(...)). So there's a bunch of code 
out 
there that uses the old approach, and in 5.4+ it's no longer considered OK. 

I'm just asking: Why should it not be OK? This example around arrays is not the 
only one, so the syntax you suggested will not apply to all cases. It seems 
unduly inflexible to disallow values to be passed in where reference aliasing 
is 
intended. So what if the caller intends to disregard the response? Why force 
them to "care enough" to create a variable of their own when that only serves 
to 
delay the freeing of that value from memory by one level of the call stack? 
Fact 
is, functions have side effects and return values and other call-by-reference 
parameters which may be what the caller is really looking for. The caller 
shouldn't need to pretend to care about every value they pass to a function 
which deems it reference aliasable.

I realize here I'm going deeper into PHP history. I just think it's an 
improvement along positive lines to relax this and not move toward strictness 
for non-utilitarian reasons. Today's E_STRICT becomes tomorrow's E_DEPRECATED 
and next week's E_ERROR. So why be picky about this when there's no ambiguity?


Previous Comments:

[2013-09-11 23:28:13] ni...@php.net

array_shift(array_splice($dbents, $x, 1)) does not throw an ERROR exception 
(whatever that is). It throws an E_STRICT level error, which is the lowest 
error type we have.

The E_STRICT tells you that you have some code that currently works, but is 
discouraged. What you were actually looking for is array_splice($dbents, $x, 
1)[0] (at least I assume so, because I don't really get your code sample.)


[2013-09-11 23:13:24] guy at syntheticwebapps dot com

Even worse, the following no longer works in PHP 5.4+ and this is an ERROR 
exception: 

$dbentry = array_shift(array_splice($dbents, $x, 1)))

This is why some leeway is appropriate on this error. I you can't chain 
together 
such logical progressions without INVENTING a variable in the code which has no 
other purpose than to avoid this ERROR exception, the language is headed the 
wrong direction and causing limitations for no cause.

I really think this needs to be fixed.


[2013-09-11 22:59:26] guy at syntheticwebapps dot com

I have a different example than the one given. Consider:

function myfunc( &$refvar ) {
  ...
}

$horse = myfunc( $value = array() );

The code example above also gets the same exception, however, this does not 
seem 
correct. This suggests that the type of "$value = array()" is expression and 
not 
a variable. But this violates an assumption in the language. Is this assumption 
incorrect? Should it be incorrect?

As in the original reported form of the problem, I believe there should be some 
forgiveness in the call-by-reference receiver. I can understand why NOT to do 
that, but there are safe ways to do it anyway, like create a new zval for local 
use. 

But it's more important to me that $value = array() evaluates to the VARIABLE 
$value and NOT an expression. What expression could it possibly represent? The 
supposed expression in such a case is meaningless, whereas the variable is 
meaningful and useful. Any chance this could be fixed in future?


[2013-05-02 08:25:11] paj...@php.net

See www.php.net/array_pop.

Using: array_pop(array_keys($a)); array_keys($a) is an expression while 
array_pop 
expects a variable. ($k = array_keys($a);...).


[2013-05-02 08:03:55] eth at ethaniel dot com

Description:

I get a "PHP Strict Standards:  Only variables should be passed by reference 
in" 
error where there should be none.

Test script:
---
echo array_pop(array_keys(array("erwre")));

Expected result:

Result: 0.

Actual result:
--
The script returns the result (0), but also a "PHP Strict Standards:  Only 
variables should be passed by reference in" in my error log.






-- 

Req #65656 [Opn]: Error message when type hinting is ambigious

[aharvey]

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

 ID: 65656
 Updated by: ahar...@php.net
 Reported by:ss23 at ss23 dot geek dot nz
 Summary:Error message when type hinting is ambigious
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Makes sense to me.

Pull request implementing this on master for someone with Zend karma:
https://github.com/php/php-src/pull/442


Previous Comments:

[2013-09-12 00:29:13] ss23 at ss23 dot geek dot nz

Description:

When you type hint with a name of a type PHP has, the error message is 
ambiguous 
and confusing.

Test script:
---
function foo(boolean $bar) {
  var_dump($bar);
}

foo(true);

Expected result:

Catchable fatal error: Argument 1 passed to foo() must be an instance of the 
class 
boolean, non-class of type boolean given, called in /code/VhrCdK on line 11 and 
defined in /code/VhrCdK on line 3

This is just my first thoughts on how to make it less confusing. Other 
suggestions 
would be apperciated.

Actual result:
--
Catchable fatal error: Argument 1 passed to foo() must be an instance of 
boolean, 
boolean given, called in /code/VhrCdK on line 11 and defined in /code/VhrCdK on 
line 3






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

[PHP-BUG] Req #65656 [NEW]: Error message when type hinting is ambigious

[ss23 at ss23 dot geek dot nz]

From: ss23 at ss23 dot geek dot nz
Operating system: 
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:Error message when type hinting is ambigious

Description:

When you type hint with a name of a type PHP has, the error message is
ambiguous 
and confusing.

Test script:
---
function foo(boolean $bar) {
  var_dump($bar);
}

foo(true);

Expected result:

Catchable fatal error: Argument 1 passed to foo() must be an instance of
the class 
boolean, non-class of type boolean given, called in /code/VhrCdK on line 11
and 
defined in /code/VhrCdK on line 3

This is just my first thoughts on how to make it less confusing. Other
suggestions 
would be apperciated.

Actual result:
--
Catchable fatal error: Argument 1 passed to foo() must be an instance of
boolean, 
boolean given, called in /code/VhrCdK on line 11 and defined in
/code/VhrCdK on 
line 3

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

Bug #64755 [Nab]: Only variables should be passed by reference

[nikic]

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

 ID: 64755
 Updated by: ni...@php.net
 Reported by:eth at ethaniel dot com
 Summary:Only variables should be passed by reference
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian 7.0
 PHP Version:5.4.14
 Block user comment: N
 Private report: N

 New Comment:

array_shift(array_splice($dbents, $x, 1)) does not throw an ERROR exception 
(whatever that is). It throws an E_STRICT level error, which is the lowest 
error type we have.

The E_STRICT tells you that you have some code that currently works, but is 
discouraged. What you were actually looking for is array_splice($dbents, $x, 
1)[0] (at least I assume so, because I don't really get your code sample.)


Previous Comments:

[2013-09-11 23:13:24] guy at syntheticwebapps dot com

Even worse, the following no longer works in PHP 5.4+ and this is an ERROR 
exception: 

$dbentry = array_shift(array_splice($dbents, $x, 1)))

This is why some leeway is appropriate on this error. I you can't chain 
together 
such logical progressions without INVENTING a variable in the code which has no 
other purpose than to avoid this ERROR exception, the language is headed the 
wrong direction and causing limitations for no cause.

I really think this needs to be fixed.


[2013-09-11 22:59:26] guy at syntheticwebapps dot com

I have a different example than the one given. Consider:

function myfunc( &$refvar ) {
  ...
}

$horse = myfunc( $value = array() );

The code example above also gets the same exception, however, this does not 
seem 
correct. This suggests that the type of "$value = array()" is expression and 
not 
a variable. But this violates an assumption in the language. Is this assumption 
incorrect? Should it be incorrect?

As in the original reported form of the problem, I believe there should be some 
forgiveness in the call-by-reference receiver. I can understand why NOT to do 
that, but there are safe ways to do it anyway, like create a new zval for local 
use. 

But it's more important to me that $value = array() evaluates to the VARIABLE 
$value and NOT an expression. What expression could it possibly represent? The 
supposed expression in such a case is meaningless, whereas the variable is 
meaningful and useful. Any chance this could be fixed in future?


[2013-05-02 08:25:11] paj...@php.net

See www.php.net/array_pop.

Using: array_pop(array_keys($a)); array_keys($a) is an expression while 
array_pop 
expects a variable. ($k = array_keys($a);...).


[2013-05-02 08:03:55] eth at ethaniel dot com

Description:

I get a "PHP Strict Standards:  Only variables should be passed by reference 
in" 
error where there should be none.

Test script:
---
echo array_pop(array_keys(array("erwre")));

Expected result:

Result: 0.

Actual result:
--
The script returns the result (0), but also a "PHP Strict Standards:  Only 
variables should be passed by reference in" in my error log.






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

Bug #64755 [Com]: Only variables should be passed by reference

[guy at syntheticwebapps dot com]

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

 ID: 64755
 Comment by: guy at syntheticwebapps dot com
 Reported by:eth at ethaniel dot com
 Summary:Only variables should be passed by reference
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian 7.0
 PHP Version:5.4.14
 Block user comment: N
 Private report: N

 New Comment:

Even worse, the following no longer works in PHP 5.4+ and this is an ERROR 
exception: 

$dbentry = array_shift(array_splice($dbents, $x, 1)))

This is why some leeway is appropriate on this error. I you can't chain 
together 
such logical progressions without INVENTING a variable in the code which has no 
other purpose than to avoid this ERROR exception, the language is headed the 
wrong direction and causing limitations for no cause.

I really think this needs to be fixed.


Previous Comments:

[2013-09-11 22:59:26] guy at syntheticwebapps dot com

I have a different example than the one given. Consider:

function myfunc( &$refvar ) {
  ...
}

$horse = myfunc( $value = array() );

The code example above also gets the same exception, however, this does not 
seem 
correct. This suggests that the type of "$value = array()" is expression and 
not 
a variable. But this violates an assumption in the language. Is this assumption 
incorrect? Should it be incorrect?

As in the original reported form of the problem, I believe there should be some 
forgiveness in the call-by-reference receiver. I can understand why NOT to do 
that, but there are safe ways to do it anyway, like create a new zval for local 
use. 

But it's more important to me that $value = array() evaluates to the VARIABLE 
$value and NOT an expression. What expression could it possibly represent? The 
supposed expression in such a case is meaningless, whereas the variable is 
meaningful and useful. Any chance this could be fixed in future?


[2013-05-02 08:25:11] paj...@php.net

See www.php.net/array_pop.

Using: array_pop(array_keys($a)); array_keys($a) is an expression while 
array_pop 
expects a variable. ($k = array_keys($a);...).


[2013-05-02 08:03:55] eth at ethaniel dot com

Description:

I get a "PHP Strict Standards:  Only variables should be passed by reference 
in" 
error where there should be none.

Test script:
---
echo array_pop(array_keys(array("erwre")));

Expected result:

Result: 0.

Actual result:
--
The script returns the result (0), but also a "PHP Strict Standards:  Only 
variables should be passed by reference in" in my error log.






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

Bug #64755 [Com]: Only variables should be passed by reference

[guy at syntheticwebapps dot com]

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

 ID: 64755
 Comment by: guy at syntheticwebapps dot com
 Reported by:eth at ethaniel dot com
 Summary:Only variables should be passed by reference
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian 7.0
 PHP Version:5.4.14
 Block user comment: N
 Private report: N

 New Comment:

I have a different example than the one given. Consider:

function myfunc( &$refvar ) {
  ...
}

$horse = myfunc( $value = array() );

The code example above also gets the same exception, however, this does not 
seem 
correct. This suggests that the type of "$value = array()" is expression and 
not 
a variable. But this violates an assumption in the language. Is this assumption 
incorrect? Should it be incorrect?

As in the original reported form of the problem, I believe there should be some 
forgiveness in the call-by-reference receiver. I can understand why NOT to do 
that, but there are safe ways to do it anyway, like create a new zval for local 
use. 

But it's more important to me that $value = array() evaluates to the VARIABLE 
$value and NOT an expression. What expression could it possibly represent? The 
supposed expression in such a case is meaningless, whereas the variable is 
meaningful and useful. Any chance this could be fixed in future?


Previous Comments:

[2013-05-02 08:25:11] paj...@php.net

See www.php.net/array_pop.

Using: array_pop(array_keys($a)); array_keys($a) is an expression while 
array_pop 
expects a variable. ($k = array_keys($a);...).


[2013-05-02 08:03:55] eth at ethaniel dot com

Description:

I get a "PHP Strict Standards:  Only variables should be passed by reference 
in" 
error where there should be none.

Test script:
---
echo array_pop(array_keys(array("erwre")));

Expected result:

Result: 0.

Actual result:
--
The script returns the result (0), but also a "PHP Strict Standards:  Only 
variables should be passed by reference in" in my error log.






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

Req #65652 [Com]: isset alternative

[anon at anon dot anon]

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

 ID: 65652
 Comment by: anon at anon dot anon
 Reported by:kozak at eurosat dot cz
 Summary:isset alternative
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   ALL
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

echo array_key_exists('b', get_defined_vars()) ? "exists" : "doesn't exist";


Previous Comments:

[2013-09-11 12:34:01] kozak at eurosat dot cz

Description:

At the moment isset call return true only when variable is set and it is not 
null.

But there is no way (or I do not find it so far), how to just test variable for 
existance. So it will be perfect if there will be some other call (for eg: 
exist) 
or some parametr how to get this behaviour
More in example. 

Test script:
---
$a = null;
$testOnlyExistence = true;

echo isset($b); // prints false;
echo isset($a); // prints false;
echo isset($a, $testOnlyExistence); // prints true;
echo isset($b, $testOnlyExistence); // prints false;
// or
echo exist($a); // prints true;
echo exist($b); // prints false;







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

Req #65652 [Wfx]: isset alternative

[kozak at eurosat dot cz]

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

 ID: 65652
 User updated by:kozak at eurosat dot cz
 Reported by:kozak at eurosat dot cz
 Summary:isset alternative
 Status: Wont fix
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   ALL
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

aharvey not it is not. Because array_key_exists is slow.


Previous Comments:

[2013-09-11 20:14:59] ahar...@php.net

It's an unusual enough need that I think the get_defined_vars() solution posted 
in the previous comment is good enough.


[2013-09-11 17:45:31] anon at anon dot anon

echo array_key_exists('b', get_defined_vars()) ? "exists" : "doesn't exist";


[2013-09-11 12:34:01] kozak at eurosat dot cz

Description:

At the moment isset call return true only when variable is set and it is not 
null.

But there is no way (or I do not find it so far), how to just test variable for 
existance. So it will be perfect if there will be some other call (for eg: 
exist) 
or some parametr how to get this behaviour
More in example. 

Test script:
---
$a = null;
$testOnlyExistence = true;

echo isset($b); // prints false;
echo isset($a); // prints false;
echo isset($a, $testOnlyExistence); // prints true;
echo isset($b, $testOnlyExistence); // prints false;
// or
echo exist($a); // prints true;
echo exist($b); // prints false;







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

Bug #60586 [Com]: ignore_user_abort=true has no effect on IIS with FastCGI

[curibe at microsoft dot com]

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

 ID: 60586
 Comment by: curibe at microsoft dot com
 Reported by:sauvant at aspera dot com
 Summary:ignore_user_abort=true has no effect on IIS with
 FastCGI
 Status: Open
 Type:   Bug
 Package:IIS related
 Operating System:   Windows Server 2008 R2
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

We investigated this issue from an IIS perspective by reproducing the issue 
using the sample page listed in this bug and setting ignore_user_abort=true we 
saw the following behavior:
Shortly after the browser disconnects, we get a failure on the named pipe 
connection to the php-cgi.exe process indicating that pipe was disconnected.  
That takes us to a path that terminates that process.  We do this because, once 
the FastCGI process has disconnected, we can no longer manage it.  To prevent 
it from consuming system resources, we terminate it.  This is all by design, 
and it may be different on other web servers if they allow processes to run 
after they’ve disconnected.
We also verified that we are not closing the pipe on our side prior to 
terminating the process.  It is definitely getting closed on the FastCGI 
process side.


Previous Comments:

[2012-12-07 01:27:57] ahar...@php.net

A pull request or patch would be much appreciated, I'm sure. :)


[2012-12-06 12:43:25] rainer at dueckerhoff dot de

This bug still persists in the latest 5.3 version after about a year of this 
bug 
report.
Any chance that it could be fixed or any explanation on why it doesn't work 
with 
IIS but with Apache (and thus cannot be fixed)? Or at least a workaround?

Cheers,
Rainer


[2012-07-10 12:32:43] sauvant at aspera dot com

There is a thread at the IIS forum, too: http://forums.iis.net/t/1190270.aspx
No feedback at all :-(

Is the issue described PHP or IIS related? 
Any opinions?
Anybody able to reproduce?

Best regards
Keith


[2012-06-25 15:00:50] lars_teuber at gmx dot de

Microsoft-IIS/7.5. Best regards, Lars.


[2012-06-25 14:54:00] larue...@php.net

you mean IIS or nginx?  thanks :)




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

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


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

Req #65652 [Opn->Wfx]: isset alternative

[aharvey]

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

 ID: 65652
 Updated by: ahar...@php.net
 Reported by:kozak at eurosat dot cz
 Summary:isset alternative
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   ALL
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

It's an unusual enough need that I think the get_defined_vars() solution posted 
in the previous comment is good enough.


Previous Comments:

[2013-09-11 17:45:31] anon at anon dot anon

echo array_key_exists('b', get_defined_vars()) ? "exists" : "doesn't exist";


[2013-09-11 12:34:01] kozak at eurosat dot cz

Description:

At the moment isset call return true only when variable is set and it is not 
null.

But there is no way (or I do not find it so far), how to just test variable for 
existance. So it will be perfect if there will be some other call (for eg: 
exist) 
or some parametr how to get this behaviour
More in example. 

Test script:
---
$a = null;
$testOnlyExistence = true;

echo isset($b); // prints false;
echo isset($a); // prints false;
echo isset($a, $testOnlyExistence); // prints true;
echo isset($b, $testOnlyExistence); // prints false;
// or
echo exist($a); // prints true;
echo exist($b); // prints false;







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

Bug #65634 [Asn->Csd]: HTTP wrapper is very slow with protocol_version 1.1

[aharvey]

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

 ID: 65634
 Updated by: ahar...@php.net
 Reported by:butesa at freenet dot de
 Summary:HTTP wrapper is very slow with protocol_version 1.1
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:HTTP related
 Operating System:   Ubuntu 12.04 x64
 PHP Version:5.5.3
 Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

Implemented on master:
https://github.com/php/php-src/commit/8983a38d5130c11bd96643dfa2b2f1393ac5969d

I don't think this is a good candidate for 5.4 or 5.5: it's debatable whether 
this is a bug fix, and it does subtly change PHP's behaviour. I'd be surprised 
if 
it broke any code, but it should be something users have to test, and putting 
it 
in the next version should ensure that.


Previous Comments:

[2013-09-11 20:30:19] ahar...@php.net

Fair point. Let me see if we can send a Connection: close request header by 
default and allow overriding via the headers context option if the user wants 
it 
for some reason.


[2013-09-10 19:43:18] butesa at freenet dot de

I looked into RFC 2616 today. It says:
HTTP/1.1 applications that do not support persistent connections MUST include 
the "close" connection option in every message.

Obviously, the HTTP wrapper can't handle persistent connections correctly. So 
it should automatically add a Connection: close header when protocol_version is 
set to 1.1.


[2013-09-09 23:52:31] butesa at freenet dot de

I don't see how it can be not a bug if a http request takes 100 seconds.
If the server uses connection: keep-alive, then the client has to close the 
connection if it doesn't want to make any further requests.


[2013-09-09 23:03:47] ahar...@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

www.google.de responds with a keep-alive connection when a HTTP/1.1 request is 
made and no Connection request header is included, which is valid in RFC 2616. 
Sending a "Connection: close" request header restores the 1.0 behaviour.


[2013-09-08 16:27:47] butesa at freenet dot de

Description:

Loading a website with the http wrapper takes very long if protocol_version is 
set to 1.1. The time it takes depends on the timeout. On some servers the 
problem doesn't occur.

I tested also on Ubuntu 10.04 (PHP 5.3.2-1ubuntu4.19) and Ubuntu 12.04 (PHP 
5.3.10-1ubuntu3.7), both 64bit.

Test script:
---
http://www.google.de/intl/de/policies/?fg=1';
foreach(array(1.0,1.1) as $proto)
{
for ($timeout = 1; $timeout < 60; $timeout+=10)
{
$st = microtime(true);
$opt = array(
'http' => array(
'timeout' => $timeout,
'protocol_version' => $proto,
),
);
$context = stream_context_create($opt);
$content = file_get_contents($url,false,$context);
printf("%2d %.1f %f %s\n", $timeout, $proto, microtime(true) - 
$st, md5($content));
}
}
?>

Expected result:

The request takes the same time, no matter what timeout and protocol_version is 
set.

Actual result:
--
Output of the test script:
For $url='http://www.google.de/intl/de/policies/?fg=1':
 1 1.0 0.279102 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.0 0.277956 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.0 0.283753 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.0 0.285862 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.0 0.277894 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.0 0.285653 60bf7bc72d2a06b337c8a8464e0f9e66
 1 1.1 2.284301 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.1 22.305424 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.1 42.309270 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.1 62.355997 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.1 82.360794 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.1 102.379933 60bf7bc72d2a06b337c8a8464e0f9e66

For $url='http://www.example.com':
 1 1.0 0.491382 09b9c392dc1f6e914cea287cb6be34b0
11 1.0 0.426191 09b9c392dc1f6e914cea287cb6be34b0
21 1.0 0.428513 09b9c392dc1f6e914cea287cb6be34b0
31 1.0 0.423852 09b9c392dc1f6e914cea287cb6be34b0
41 1.0 0.423751 09b9c392dc1f6e914cea287cb6be34b0
51 1.0 0.431590 09b9c392dc1f6e914cea287cb6be34b0
 1 1.1 1.420486 09b9c392dc1f6e914cea287cb6be34b0
11 1.1 6.143113 09b9c392dc1f6e914cea287cb6be34b0
21 1.1 5.994

Bug #60749 [Com]: SNMP module should not strip non-standard SNMP port from hostname

[hexetic at gmail dot com]

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

 ID: 60749
 Comment by: hexetic at gmail dot com
 Reported by:lytbo...@php.net
 Summary:SNMP module should not strip non-standard SNMP port
 from hostname
 Status: No Feedback
 Type:   Bug
 Package:SNMP related
 Operating System:   *
 PHP Version:5.4.0RC5
 Assigned To:lytboris
 Block user comment: N
 Private report: N

 New Comment:

In reply to my own comment earlier today, I have checked the "stock" versions 
of PHP, and I observe that the issue does not seem to exist in a 
freshly-compiled PHP 5.5.3 or PHP 5.4.19. I will look into possibly reporting 
this derived issue to Debian instead.


Previous Comments:

[2013-09-11 18:40:03] lytbo...@php.net

You need patch from bug report #64124, not this one.


[2013-09-11 17:32:08] hexetic at gmail dot com

The fix checked-in seems to break passing-in "hostname:port" as $hostname to 
the snmp functions, e.g.:



After the call to snmp2_get, $host is "192.168.0.1001616" -- i.e., the colon 
has been removed. As a result, calling snmp2_get or any of the other functional 
snmp parameters is likely to fail after the first time.

We are experiencing this with the current version of PHP in Debian Squeeze, 
i.e.:
$ php --version
PHP 5.4.4-14+deb7u4 (cli) (built: Aug 23 2013 14:37:41) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

The codebase for this version appears to have lytbo...@php.net's patch.


[2013-02-08 05:10:19] lytbo...@php.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-07-24 23:37:45] ras...@php.net

Automatic comment on behalf of lytboris
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4
Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is 
disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port 
from hostname) Fixed ipv6 test skipto if IPv6 support is disabled


[2012-04-18 09:46:36] larue...@php.net

Automatic comment on behalf of lytboris
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4
Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is 
disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port 
from hostname) Fixed ipv6 test skipto if IPv6 support is disabled




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


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

Bug #65634 [Nab->Asn]: HTTP wrapper is very slow with protocol_version 1.1

[aharvey]

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

 ID: 65634
 Updated by: ahar...@php.net
 Reported by:butesa at freenet dot de
 Summary:HTTP wrapper is very slow with protocol_version 1.1
-Status: Not a bug
+Status: Assigned
 Type:   Bug
 Package:HTTP related
 Operating System:   Ubuntu 12.04 x64
 PHP Version:5.5.3
-Assigned To:
+Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

Fair point. Let me see if we can send a Connection: close request header by 
default and allow overriding via the headers context option if the user wants 
it 
for some reason.


Previous Comments:

[2013-09-10 19:43:18] butesa at freenet dot de

I looked into RFC 2616 today. It says:
HTTP/1.1 applications that do not support persistent connections MUST include 
the "close" connection option in every message.

Obviously, the HTTP wrapper can't handle persistent connections correctly. So 
it should automatically add a Connection: close header when protocol_version is 
set to 1.1.


[2013-09-09 23:52:31] butesa at freenet dot de

I don't see how it can be not a bug if a http request takes 100 seconds.
If the server uses connection: keep-alive, then the client has to close the 
connection if it doesn't want to make any further requests.


[2013-09-09 23:03:47] ahar...@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

www.google.de responds with a keep-alive connection when a HTTP/1.1 request is 
made and no Connection request header is included, which is valid in RFC 2616. 
Sending a "Connection: close" request header restores the 1.0 behaviour.


[2013-09-08 16:27:47] butesa at freenet dot de

Description:

Loading a website with the http wrapper takes very long if protocol_version is 
set to 1.1. The time it takes depends on the timeout. On some servers the 
problem doesn't occur.

I tested also on Ubuntu 10.04 (PHP 5.3.2-1ubuntu4.19) and Ubuntu 12.04 (PHP 
5.3.10-1ubuntu3.7), both 64bit.

Test script:
---
http://www.google.de/intl/de/policies/?fg=1';
foreach(array(1.0,1.1) as $proto)
{
for ($timeout = 1; $timeout < 60; $timeout+=10)
{
$st = microtime(true);
$opt = array(
'http' => array(
'timeout' => $timeout,
'protocol_version' => $proto,
),
);
$context = stream_context_create($opt);
$content = file_get_contents($url,false,$context);
printf("%2d %.1f %f %s\n", $timeout, $proto, microtime(true) - 
$st, md5($content));
}
}
?>

Expected result:

The request takes the same time, no matter what timeout and protocol_version is 
set.

Actual result:
--
Output of the test script:
For $url='http://www.google.de/intl/de/policies/?fg=1':
 1 1.0 0.279102 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.0 0.277956 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.0 0.283753 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.0 0.285862 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.0 0.277894 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.0 0.285653 60bf7bc72d2a06b337c8a8464e0f9e66
 1 1.1 2.284301 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.1 22.305424 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.1 42.309270 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.1 62.355997 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.1 82.360794 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.1 102.379933 60bf7bc72d2a06b337c8a8464e0f9e66

For $url='http://www.example.com':
 1 1.0 0.491382 09b9c392dc1f6e914cea287cb6be34b0
11 1.0 0.426191 09b9c392dc1f6e914cea287cb6be34b0
21 1.0 0.428513 09b9c392dc1f6e914cea287cb6be34b0
31 1.0 0.423852 09b9c392dc1f6e914cea287cb6be34b0
41 1.0 0.423751 09b9c392dc1f6e914cea287cb6be34b0
51 1.0 0.431590 09b9c392dc1f6e914cea287cb6be34b0
 1 1.1 1.420486 09b9c392dc1f6e914cea287cb6be34b0
11 1.1 6.143113 09b9c392dc1f6e914cea287cb6be34b0
21 1.1 5.994384 09b9c392dc1f6e914cea287cb6be34b0
31 1.1 5.991940 09b9c392dc1f6e914cea287cb6be34b0
41 1.1 6.012121 09b9c392dc1f6e914cea287cb6be34b0
51 1.1 6.007920 09b9c392dc1f6e914cea287cb6be34b0

For $url='http://www.php.net':
 1 1.0 1.673016 2dcc6fe85b335205a35d9980a9095735
11 1.0 1.93 2dcc6fe85b335205a35d9980a9095735
21 1.0 1.648235 2dcc6fe85b335205a35d9980a9095735
31 1.0 1.637566 2dcc6fe85b335205a35d9980a9095735
41 1.0 1.633473 2dcc6fe85b335205a35d9980a9095735
51 1.0 1.718051 

Bug #60749 [NoF]: SNMP module should not strip non-standard SNMP port from hostname

[lytboris]

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

 ID: 60749
 Updated by: lytbo...@php.net
 Reported by:lytbo...@php.net
 Summary:SNMP module should not strip non-standard SNMP port
 from hostname
 Status: No Feedback
 Type:   Bug
 Package:SNMP related
 Operating System:   *
 PHP Version:5.4.0RC5
 Assigned To:lytboris
 Block user comment: N
 Private report: N

 New Comment:

You need patch from bug report #64124, not this one.


Previous Comments:

[2013-09-11 17:32:08] hexetic at gmail dot com

The fix checked-in seems to break passing-in "hostname:port" as $hostname to 
the snmp functions, e.g.:



After the call to snmp2_get, $host is "192.168.0.1001616" -- i.e., the colon 
has been removed. As a result, calling snmp2_get or any of the other functional 
snmp parameters is likely to fail after the first time.

We are experiencing this with the current version of PHP in Debian Squeeze, 
i.e.:
$ php --version
PHP 5.4.4-14+deb7u4 (cli) (built: Aug 23 2013 14:37:41) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

The codebase for this version appears to have lytbo...@php.net's patch.


[2013-02-08 05:10:19] lytbo...@php.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-07-24 23:37:45] ras...@php.net

Automatic comment on behalf of lytboris
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4
Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is 
disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port 
from hostname) Fixed ipv6 test skipto if IPv6 support is disabled


[2012-04-18 09:46:36] larue...@php.net

Automatic comment on behalf of lytboris
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4
Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is 
disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port 
from hostname) Fixed ipv6 test skipto if IPv6 support is disabled


[2012-01-13 18:48:17] lytbo...@php.net

Please try using this snapshot:

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

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






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


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

Bug #60749 [Com]: SNMP module should not strip non-standard SNMP port from hostname

[hexetic at gmail dot com]

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

 ID: 60749
 Comment by: hexetic at gmail dot com
 Reported by:lytbo...@php.net
 Summary:SNMP module should not strip non-standard SNMP port
 from hostname
 Status: No Feedback
 Type:   Bug
 Package:SNMP related
 Operating System:   *
 PHP Version:5.4.0RC5
 Assigned To:lytboris
 Block user comment: N
 Private report: N

 New Comment:

The fix checked-in seems to break passing-in "hostname:port" as $hostname to 
the snmp functions, e.g.:



After the call to snmp2_get, $host is "192.168.0.1001616" -- i.e., the colon 
has been removed. As a result, calling snmp2_get or any of the other functional 
snmp parameters is likely to fail after the first time.

We are experiencing this with the current version of PHP in Debian Squeeze, 
i.e.:
$ php --version
PHP 5.4.4-14+deb7u4 (cli) (built: Aug 23 2013 14:37:41) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

The codebase for this version appears to have lytbo...@php.net's patch.


Previous Comments:

[2013-02-08 05:10:19] lytbo...@php.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-07-24 23:37:45] ras...@php.net

Automatic comment on behalf of lytboris
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4
Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is 
disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port 
from hostname) Fixed ipv6 test skipto if IPv6 support is disabled


[2012-04-18 09:46:36] larue...@php.net

Automatic comment on behalf of lytboris
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4
Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is 
disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port 
from hostname) Fixed ipv6 test skipto if IPv6 support is disabled


[2012-01-13 18:48:17] lytbo...@php.net

Please try using this snapshot:

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

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




[2012-01-13 18:46:27] lytbo...@php.net

Automatic comment from SVN on behalf of lytboris
Revision: http://svn.php.net/viewvc/?view=revision&revision=322214
Log: merge from trunk:
Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is 
disabled
Fixed bug #60749 (SNMP module should not strip non-standard SNMP port from 
hostname




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


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

Bug #65654 [Com]: Extending DateInterval and unable to use $this->days

[steven at gowebprint dot com]

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

 ID: 65654
 Comment by: steven at gowebprint dot com
 Reported by:steven at gowebprint dot com
 Summary:Extending DateInterval and unable to use $this->days
 Status: Open
 Type:   Bug
 Package:Date/time related
 Operating System:   Cent OS 6.4
 PHP Version:5.4.19
 Block user comment: N
 Private report: N

 New Comment:

You are right.

I have extended DateTime object and overrides the diff method with

public function diff ($datetime2 , $absolute = false){
return new DateInterval(parent::diff($datetime2,$absolute));
}

If you look at the sample code that would be return the DateInterval in the 
test namespace.

Since I am overriding the diff method I want to return a DateInterval object 
that behaves like it would from \DateTime which includes a populated days 
property , but I have no way of setting the days property or telling \DateTime 
to return a different DateInterval object, so I am unable to return a 
DateInteral object with a days property filled and returned from the diff 
method as expected.

The manual says:

If the DateInterval object was created by DateTime::diff(), then this is the 
total number of days between the start and end dates. Otherwise, days will be 
FALSE.

This is the method I have overridden and I am trying to return a extended 
DateInterval object, whilst keeping the all of the DateInterval property's 
intact including days.


Previous Comments:

[2013-09-11 13:36:48] der...@php.net

"I am trying to extend DateTime and DaveInterval to add extra functionality to 
the core classes, but I have been unable to write to $this->days internally to 
the object."

That's not really a bug. "days" is a calculated version that only make sense in 
the context of having compared two other DateTime objects. Without those other 
two objects presents, its value makes no sense.


[2013-09-11 13:26:49] steven at gowebprint dot com

Description:

I am trying to extend DateTime and DaveInterval to add extra functionality to 
the core classes, but I have been unable to write to $this->days internally to 
the object.

As a side note, I have been able to cause a seg fault within our application 
when writing to $interval->days = 100 externally, but unable to reproduce on a 
small script.

Test script:
---
http://pastebin.com/tBay704K

Expected result:

object(DateInterval)[3]
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'days' => int 365
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0
object(test\DateInterval)[4]
  public 'days' => int 365
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0

Actual result:
--
object(DateInterval)[3]
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'days' => int 365
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0
object(test\DateInterval)[4]
  public 'days' => boolean false
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0






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

Bug #65654 [Opn]: Extending DateInterval and unable to use $this->days

[derick]

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

 ID: 65654
 Updated by: der...@php.net
 Reported by:steven at gowebprint dot com
 Summary:Extending DateInterval and unable to use $this->days
 Status: Open
 Type:   Bug
 Package:Date/time related
 Operating System:   Cent OS 6.4
 PHP Version:5.4.19
 Block user comment: N
 Private report: N

 New Comment:

"I am trying to extend DateTime and DaveInterval to add extra functionality to 
the core classes, but I have been unable to write to $this->days internally to 
the object."

That's not really a bug. "days" is a calculated version that only make sense in 
the context of having compared two other DateTime objects. Without those other 
two objects presents, its value makes no sense.


Previous Comments:

[2013-09-11 13:26:49] steven at gowebprint dot com

Description:

I am trying to extend DateTime and DaveInterval to add extra functionality to 
the core classes, but I have been unable to write to $this->days internally to 
the object.

As a side note, I have been able to cause a seg fault within our application 
when writing to $interval->days = 100 externally, but unable to reproduce on a 
small script.

Test script:
---
http://pastebin.com/tBay704K

Expected result:

object(DateInterval)[3]
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'days' => int 365
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0
object(test\DateInterval)[4]
  public 'days' => int 365
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0

Actual result:
--
object(DateInterval)[3]
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'days' => int 365
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0
object(test\DateInterval)[4]
  public 'days' => boolean false
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0






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

[PHP-BUG] Bug #65654 [NEW]: Extending DateInterval and unable to use $this->days

[steven at gowebprint dot com]

From: steven at gowebprint dot com
Operating system: Cent OS 6.4
PHP version:  5.4.19
Package:  Date/time related
Bug Type: Bug
Bug description:Extending DateInterval and unable to use $this->days

Description:

I am trying to extend DateTime and DaveInterval to add extra functionality
to the core classes, but I have been unable to write to $this->days
internally to the object.

As a side note, I have been able to cause a seg fault within our
application when writing to $interval->days = 100 externally, but unable to
reproduce on a small script.

Test script:
---
http://pastebin.com/tBay704K

Expected result:

object(DateInterval)[3]
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'days' => int 365
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0
object(test\DateInterval)[4]
  public 'days' => int 365
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0

Actual result:
--
object(DateInterval)[3]
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'days' => int 365
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0
object(test\DateInterval)[4]
  public 'days' => boolean false
  public 'y' => int 1
  public 'm' => int 0
  public 'd' => int 0
  public 'h' => int 0
  public 'i' => int 0
  public 's' => int 0
  public 'weekday' => int 0
  public 'weekday_behavior' => int 0
  public 'first_last_day_of' => int 0
  public 'invert' => int 1
  public 'special_type' => int 0
  public 'special_amount' => int 0
  public 'have_weekday_relative' => int 0
  public 'have_special_relative' => int 0

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

[PHP-BUG] Req #65652 [NEW]: isset alternative

[kozak at eurosat dot cz]

From: kozak at eurosat dot cz
Operating system: ALL
PHP version:  5.5.3
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:isset alternative

Description:

At the moment isset call return true only when variable is set and it is
not 
null.

But there is no way (or I do not find it so far), how to just test variable
for 
existance. So it will be perfect if there will be some other call (for eg:
exist) 
or some parametr how to get this behaviour
More in example. 

Test script:
---
$a = null;
$testOnlyExistence = true;

echo isset($b); // prints false;
echo isset($a); // prints false;
echo isset($a, $testOnlyExistence); // prints true;
echo isset($b, $testOnlyExistence); // prints false;
// or
echo exist($a); // prints true;
echo exist($b); // prints false;


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

Bug #64874 [Com]: json_decode handles whitespace and case-sensitivity incorrectly

[ajf at ajf dot me]

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

 ID: 64874
 Comment by: ajf at ajf dot me
 Reported by:chrivers at iversen-net dot dk
 Summary:json_decode handles whitespace and case-sensitivity
 incorrectly
 Status: Open
 Type:   Bug
 Package:JSON related
 Operating System:   All
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

Submitted pull request: https://github.com/php/php-src/pull/436


Previous Comments:

[2013-09-09 17:05:34] cmbecker69 at gmx dot de

There is a RFC[1] to replace the current JSON implementation with
the jsonc PECL extension, so "fixing" that implementation may not 
be reasonable anyway.

[1] 


[2013-09-09 16:24:12] ajf at ajf dot me

D:\Projects>php -r "var_dump(json_decode('tRUe'));"
bool(true)

Seems to still be broken, I'll try to fix it.


[2013-05-19 20:04:53] chrivers at iversen-net dot dk

Well, the part of the RFC that you're quoting describes the "JSON-text" type, 
which indeed must be non-
primitive.

However, the json_decode() function is documented as taking a "json value", 
which according to the spec 
is 

"""
   A JSON value MUST be an object, array, number, or string, or one of
   the following three literal names:

  false null true
"""

So that's perfectly fine, really.

There are other errors, too. For example, " true" WORKS while "true " fails, 
which makes no sense at 
all. I've created an updated test case:

 0],
$error[json_decode($x) !== $y]
  );
}

printf($fmt, "JSON", "Expected", "Actual", "JSON_ERROR", "PASS");
printf("--
\n");

// works
json_cmp("true", true);

// fails - is actually true
json_cmp("tRue", NULL);

// fails - is actually NULL
json_cmp("true ", true);

// works
json_cmp("[true ] ", array(true));
json_cmp("[ true ] ", array(true));
json_cmp("[true] ", array(true));

// works, even though the non-array version fails
json_cmp("[tRue]", NULL);

json_cmp("0", 0);
json_cmp("1", 1);

json_cmp("false", false);

json_cmp("'foo'", NULL);

json_cmp('"foo"', "foo");

json_cmp('1.123', 1.123);
json_cmp('1.123 ', 1.123);
json_cmp(' 1.123', 1.123);

json_cmp('42', 42);
json_cmp('42 ', 42);
json_cmp(' 42', 42);

json_cmp(".123", 0.123);

?>


Which gives the following results:

JSON Expected Actual   JSON_ERROR PASS 
--
'true'   true true -  -
'tRue'   NULL true -  FAIL 
'true '  true NULL FAIL   FAIL 
'[true ] '   array (  0 => true,) array (  0 => true,) -  -
'[ true ] '  array (  0 => true,) array (  0 => true,) -  -
'[true] 'array (  0 => true,) array (  0 => true,) -  -
'[tRue]' NULL NULL FAIL   -
'0'  00-  -
'1'  11-  -
'false'  falsefalse-  -
'\'foo\''NULL NULL FAIL   -
'"foo"'  'foo''foo'-  -
'1.123'  1.1231.123-  -
'1.123 ' 1.123NULL FAIL   FAIL 
' 1.123' 1.1231.123-  -
'42' 42   42   -  -
'42 '42   NULL FAIL   FAIL 
' 42'42   42   -  -
'.123'   0.1230.123-  -


I see "FAIL" 4 times, so that seems like 4 bugs to me.


[2013-05-18 15:00:32] cmbecker69 at gmx dot de

RFC 4627[1] also states in section 2:

| A JSON text is a serialized object or array.
| 
|JSON-text = object / array

According to that definition the $json argument of examples 1-3 
is not a valid JSON-text.

Furthermore:
  json_decode('true ');
  var_dump(json_last_error() === JSON_ERROR_SYNTAX);
prints:
  bool(true)
So the returned NULL is actually correct according to the documentation.

[1] 


[2013-05-17 21:48:29] chrivers at iversen-net dot dk

Description:

There are 2 problems with the json_decode function.

1) It on