Bug #61300 [Opn]: segfault in make install or interactive CLI
Edit report at https://bugs.php.net/bug.php?id=61300&edit=1 ID: 61300 User updated by:fbableus at yahoo dot fr Reported by:fbableus at yahoo dot fr -Summary:make install fails with segfault +Summary:segfault in make install or interactive CLI Status: Open Type: Bug -Package:Compile Failure +Package:Streams related Operating System: ARM -PHP Version:5.4.0 +PHP Version:5.4 Block user comment: N Private report: N New Comment: The cli binary runs but when using tab key in interactive mode, segfault occurs. Apache handler fails too. Previous Comments: [2012-03-06 12:42:57] fbableus at yahoo dot fr Description: When compiling php 5.4.0 under ARMV5tel (gcc 3.4.2) the make install command fails while attempting to install pear. make test even fails with segfault before any output. Compiling without any optimization (-O0 option) is successfull. Expected result: Successfull installation. Actual result: -- Segmentation fault -- Edit this bug report at https://bugs.php.net/bug.php?id=61300&edit=1
Bug #63875 [Com]: provide a way to handle "in Unknown on line 0" errors
Edit report at https://bugs.php.net/bug.php?id=63875&edit=1
ID: 63875
Comment by: giorgio dot liscio at email dot it
Reported by:giorgio dot liscio at email dot it
Summary:provide a way to handle "in Unknown on line 0"
errors
Status: Open
Type: Bug
Package:*General Issues
Operating System: any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
http://stackoverflow.com/questions/11738949
http://stackoverflow.com/questions/2133652
Previous Comments:
[2012-12-30 05:44:55] giorgio dot liscio at email dot it
Description:
please read carefully! I really think this is important
when an error happens before the actual script execution (main(), "unknown on
line 0") it is not possible to handle and gracefully display the
error in the user space
errors may be: "post content-length exceeded", "file upload size exceeded",
"max input time"... or the equivalent apache errors
(LimitRequestBody for instance)
note that I'm not sure, or I don't remember, what exactly happens when some of
these errors happen, but --some of them don't block the php's
execution--, like "post_max_size". But when the php's execution isn't blocked I
should be able to handle startup errors: nowadays I can't.
for example, a big file is uploaded on the server and the post data is limited
by some of the above.
now, the php page executes anyway because the "startup warning" doesn't block
the execution. But, as I said, in the user space, there is no way
what exactly happened and what caused the error, the only way to handle this is
(I suppose) parsing error_get_last().
when the big file is sent to the server i may not have the complete form data
and in the user space I can't get the proof that is complete.
the only thing i can do is if(error_get_last()) throw new Exception("Something
went wrong with your request (???)");
then something must be done here to fix this problem. I don't have the complete
view of the problem but I hope to have been clear so you can fix
this.
Some functions may be needed:
get_startup_errors();
that returns something like this:
[0][message] => Post content data limit excedeed ...
[0][startupErrType] => STARTUP_ERR_PARTIAL_POST
[1][message] => Module 'ssh2' blah blah blah
[1][startupErrType] => STARTUP_ERR_SERVER
[2]...
where startupErrType consists in constants like these:
STARTUP_ERR_PARTIAL_POST // partial data sent
STARTUP_ERR_EXCEDEED_INPUT_TIME // excedeed input time
STARTUP_ERR_EXTENSION // an extension caused the error
STARTUP_ERR_SERVER// server caused the startup error
I hope to have been clear, my English isn't good.
have a happy new year!
--
Edit this bug report at https://bugs.php.net/bug.php?id=63875&edit=1
Req #63834 [PATCH]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Patch added by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
Previous Comments:
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [Opn]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Updated by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I think it makes sense to provide the scope which calls a method. Beyond this
is
application specific, I have suggested a patch that provides the name like the
associated methods.
Previous Comments:
[2012-12-31 11:11:54] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [PATCH]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Patch added by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: 63834-2.patch
Revision: 1356953808
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356953808
Previous Comments:
[2012-12-31 11:19:32] krak...@php.net
I think it makes sense to provide the scope which calls a method. Beyond this
is
application specific, I have suggested a patch that provides the name like the
associated methods.
[2012-12-31 11:11:54] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [Opn]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Updated by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
-2 will provide get_calling_method and get_calling_class, I think that's
everything you should need
Previous Comments:
[2012-12-31 11:36:48] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834-2.patch
Revision: 1356953808
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356953808
[2012-12-31 11:19:32] krak...@php.net
I think it makes sense to provide the scope which calls a method. Beyond this
is
application specific, I have suggested a patch that provides the name like the
associated methods.
[2012-12-31 11:11:54] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [PATCH]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1
ID: 63834
Patch added by: krak...@php.net
Reported by:tolan333 at gmail dot com
Summary:Add a function to detect a methods calling context
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: 63834-2.patch
Revision: 1356954599
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356954599
Previous Comments:
[2012-12-31 11:37:55] krak...@php.net
-2 will provide get_calling_method and get_calling_class, I think that's
everything you should need
[2012-12-31 11:36:48] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834-2.patch
Revision: 1356953808
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356953808
[2012-12-31 11:19:32] krak...@php.net
I think it makes sense to provide the scope which calls a method. Beyond this
is
application specific, I have suggested a patch that provides the name like the
associated methods.
[2012-12-31 11:11:54] krak...@php.net
The following patch has been added/updated:
Patch Name: 63834.patch
Revision: 1356952314
URL:
https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314
[2012-12-22 15:46:44] tolan333 at gmail dot com
Description:
Currently it is hard to get to know the exact context from which a method is
called from. Sure, there is debug_backtrace and the Reflection API, but these
are no ideal nor complete and reliable solutions.
I suggest to introduce a new function: get_calling_context (similar to
get_calling_class).
A possible use-case is shown below
Possible return values could be:
Use case:
Currently I use virtual properties (via __get and __set) to validate and
manipulate properties data while still keeping the ability to iterate over the
entire object(implementing IteratorAggregate). This allows me also to have
different visibility states for accessors (which will hopefully be supported in
5.5 without having to rely on custom implementations) but not for the
properties themself.
Simplified __set implementation:
{'set' . \ucfirst($name)}($value);
} else {
throw new WritePropertyFromWrongContextException("virtual
property $name can not be accessed from this context");
}
} elseif (\method_exists($this, 'set' . \ucfirst($name))) {
return $this->{'set' . \ucfirst($name)}($value);
} elseif ($this->objectConfiguration['accessMapAsProps'] == true &&
$this->offsetExists($name)) {
$this[$name] =
$this->createPropertyValidator($name)->validate($value,$this->getRuleSet()[$name])->getValidatedValue();
} else {
throw new WriteNonExistingPropertyException("Virtual property
\$$name does not exist in class " .
\get_class($this));
}
}
?>
There is no possibility to react on different scenarios as there can be only
one __set which is either public,protected or private. There is no option to
implement different behaviors for different visibility.
Another usecase is the usage of object callbacks in handlers like
session.set.save.handler
For example the write callback does not (per documentation) output data.
However in debug scenarios and in unit-tests it would be ideal to know if the
method was called from the core as a usual session handler or in a different
scenario in usercode.
Additionally this would go inline with already existing functions like
get_called_class, get_parent_class and partly get_class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [Com]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1 ID: 63834 Comment by: ni...@php.net Reported by:tolan333 at gmail dot com Summary:Add a function to detect a methods calling context Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I still fail to use just what exactly this asks for and how it would be beneficial. @krakjoe: The get_calling_method and get_calling_class functions you added should already be fully covered by debug_backtrace, so I see little value in adding them (as the use case is rather limited). @op: Regarding the last two PHP_CONTEXT_EXTERN constants, what do you mean by "user" and "core"? E.g. if you invoke a callback using call_user_func, is that an internal or a userland call? It's the internal function doing the call, but it's really the user who triggers it. I don't see how these constants would carry any meaning. The other two again can be covered by debug_backtrace, can't they? Just get the class of the call and check whether it equals __CLASS__ (=> private) or is a subclass of __CLASS__ (=> protected) or is none (=> public). Seems simple enough to me. Previous Comments: [2012-12-31 11:49:59] krak...@php.net The following patch has been added/updated: Patch Name: 63834-2.patch Revision: 1356954599 URL: https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356954599 [2012-12-31 11:37:55] krak...@php.net -2 will provide get_calling_method and get_calling_class, I think that's everything you should need [2012-12-31 11:36:48] krak...@php.net The following patch has been added/updated: Patch Name: 63834-2.patch Revision: 1356953808 URL: https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356953808 [2012-12-31 11:19:32] krak...@php.net I think it makes sense to provide the scope which calls a method. Beyond this is application specific, I have suggested a patch that provides the name like the associated methods. [2012-12-31 11:11:54] krak...@php.net The following patch has been added/updated: Patch Name: 63834.patch Revision: 1356952314 URL: https://bugs.php.net/patch-display.php?bug=63834&patch=63834.patch&revision=1356952314 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=63834 -- Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Req #63834 [Opn]: Add a function to detect a methods calling context
Edit report at https://bugs.php.net/bug.php?id=63834&edit=1 ID: 63834 Updated by: krak...@php.net Reported by:tolan333 at gmail dot com Summary:Add a function to detect a methods calling context Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: acquiring a backtrace is an inefficient means of obtaining this information ... Previous Comments: [2012-12-31 11:55:17] ni...@php.net I still fail to use just what exactly this asks for and how it would be beneficial. @krakjoe: The get_calling_method and get_calling_class functions you added should already be fully covered by debug_backtrace, so I see little value in adding them (as the use case is rather limited). @op: Regarding the last two PHP_CONTEXT_EXTERN constants, what do you mean by "user" and "core"? E.g. if you invoke a callback using call_user_func, is that an internal or a userland call? It's the internal function doing the call, but it's really the user who triggers it. I don't see how these constants would carry any meaning. The other two again can be covered by debug_backtrace, can't they? Just get the class of the call and check whether it equals __CLASS__ (=> private) or is a subclass of __CLASS__ (=> protected) or is none (=> public). Seems simple enough to me. [2012-12-31 11:49:59] krak...@php.net The following patch has been added/updated: Patch Name: 63834-2.patch Revision: 1356954599 URL: https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356954599 [2012-12-31 11:37:55] krak...@php.net -2 will provide get_calling_method and get_calling_class, I think that's everything you should need [2012-12-31 11:36:48] krak...@php.net The following patch has been added/updated: Patch Name: 63834-2.patch Revision: 1356953808 URL: https://bugs.php.net/patch-display.php?bug=63834&patch=63834-2.patch&revision=1356953808 [2012-12-31 11:19:32] krak...@php.net I think it makes sense to provide the scope which calls a method. Beyond this is application specific, I have suggested a patch that provides the name like the associated methods. 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=63834 -- Edit this bug report at https://bugs.php.net/bug.php?id=63834&edit=1
Bug #61300 [Opn]: segfault in assignment
Edit report at https://bugs.php.net/bug.php?id=61300&edit=1 ID: 61300 User updated by:fbableus at yahoo dot fr Reported by:fbableus at yahoo dot fr -Summary:segfault in make install or interactive CLI +Summary:segfault in assignment Status: Open Type: Bug Package:Streams related Operating System: ARM PHP Version:5.4 Block user comment: N Private report: N New Comment: The following code produces segfault (php 5.4.10): Previous Comments: [2012-12-31 09:32:54] fbableus at yahoo dot fr The cli binary runs but when using tab key in interactive mode, segfault occurs. Apache handler fails too. [2012-03-06 12:42:57] fbableus at yahoo dot fr Description: When compiling php 5.4.0 under ARMV5tel (gcc 3.4.2) the make install command fails while attempting to install pear. make test even fails with segfault before any output. Compiling without any optimization (-O0 option) is successfull. Expected result: Successfull installation. Actual result: -- Segmentation fault -- Edit this bug report at https://bugs.php.net/bug.php?id=61300&edit=1
[PHP-BUG] Req #63879 [NEW]: add cast_object (to ARRAY) to SplFixedArray
From: gynvael at coldwind dot pl Operating system: any PHP version: 5.4.10 Package: SPL related Bug Type: Feature/Change Request Bug description:add cast_object (to ARRAY) to SplFixedArray Description: When comparing (using == operator) an ARRAY with SplFixedArray object one always gets "false", even if arrays are exact match. However, casting SplFixedArray to (array) beforehand does a correct (as far as the == operator goes anyway) comparison. For convenience it would be good to add a cast_object handler that does the same thing that SplFixedArray::toArray function does (returns a PHP ARRAY matching the SplFixedArray objects content). Details: The == operator uses cast_object handler when comparing ARRAY with SplFixedArray object. The SplFixedArray has the default PHP cast_object handler (zend_std_cast_object_tostring), which fails to convert SplFixedArray to ARRAY. In such case the comparison is always false (not equal). Adding a custom cast_object handler to SplFixedArray that does the same thing that ::toArray function does, would enable a developer to use $splarray == $array to perform a comparison, instead of using an explicit cast or calling the toArray() function explicitly (see example code below). Test script: --- toArray() == $arr); // Equal Expected result: bool(true) bool(true) bool(true) Actual result: -- bool(false) bool(true) bool(true) -- Edit bug report at https://bugs.php.net/bug.php?id=63879&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63879&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63879&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63879&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63879&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63879&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63879&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63879&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63879&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63879&r=support Expected behavior: https://bugs.php.net/fix.php?id=63879&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63879&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63879&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63879&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63879&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63879&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63879&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63879&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63879&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63879&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63879&r=mysqlcfg
Bug #63862 [Com]: Passing by reference: func($a = $b);
Edit report at https://bugs.php.net/bug.php?id=63862&edit=1
ID: 63862
Comment by: mail+php at requinix dot net
Reported by:bobwei9 at hotmail dot com
Summary:Passing by reference: func($a = $b);
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Mac OS X Mountain Lion
PHP Version:master-Git-2012-12-27 (Git)
Block user comment: N
Private report: N
New Comment:
FYI:
Expected behavior. The "value" of an assignment is just a value and not a
reference to a variable, just like how "true?$a:$b" is the value of $a and not
actually the variable $a.
I don't think it would be so difficult to change that behavior but I'm afraid
of
the consequences it might have.
There's also a more subtle change that would be required for your shorthand to
work. Assignment currently propagates the right-most operand: $a=$b=$c is
almost
equivalent* to $b=$c;$a=$c; and not $b=$c;$a=$b; Unless that changes as well
then
sort($array=[3,1,2]) would try to sort the [3,1,2] and not $array.
* $c is evaluated only once
Previous Comments:
[2012-12-27 16:57:06] bobwei9 at hotmail dot com
Description:
I don't know if this should be considered as a bug or as expected behaviour (=>
feature request).
When passing an assignment to a function which expects a variable as reference
like sort(), then an E_STRICT message is issued and nothing has changed.
What I want, is that a code like "sort($a = $b);" is executed in the same way
as "$a = $b; sort($a);".
This could help to reduce the number of little, unnecessary lines.
Test script:
---
php -r 'sort($array = [3,1,2]); var_dump($array);'
Expected result:
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
Actual result:
--
Strict Standards: Only variables should be passed by reference in Command line
code on line 1
array(3) {
[0]=>
int(3)
[1]=>
int(1)
[2]=>
int(2)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=63862&edit=1
Bug #63853 [Com]: Some of the urls are not added in $url->addchild("loc",$mainurl);
Edit report at https://bugs.php.net/bug.php?id=63853&edit=1
ID: 63853
Comment by: mail+php at requinix dot net
Reported by:sachinpkaushik at gmail dot com
Summary:Some of the urls are not added in
$url->addchild("loc",$mainurl);
Status: Open
Type: Bug
Package:DOM XML related
Operating System: Fedora Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
Given a modified version of your script where $mainurl is explicitly set to the
URL you give (in UTF-8) I get the expected XML.
It seems $venueArray has only the one item otherwise you would have discovered
a
large bug in your code. Are you sure $venueArray and $mainurl have the values
you
expect? You need to debug your script, and if you discover a real bug in PHP
itself while doing so then you can (re)open a bug report with more specific
information and something we can actually use to reproduce the problem.
Also, this is not the place to get help with your code. Find an online forum or
mailing list to ask for assistance. That lets the PHP devs focus on bugs and
gives
you the personalized feedback you may need.
Previous Comments:
[2012-12-26 05:20:40] sachinpkaushik at gmail dot com
Description:
I am trying to generate xml file for sitemap for google tracking of my site url.
I have a php file with the code mentioned(Please refer the code sent) which I
am
running on the command line with no arguments.
The code retrieves value in an array $venueArrayfrom the value recieved from
the
function $venue->getAll()
There is a foreach loop which retrieves the value from the array '$venueArray'.
In the foreach loop I have added a code to fetch url from array '$venueArray'
element 'id':-
$mainurl =$venue->getUrl(array("venueId"=>$venueD['id']));
and puts it in the xml tags with the help of the code
$url->addchild("loc",$mainurl);
and then the contents are appended in the file.
It seems that some of the urls are not added (url for example:
http://mysite.com/dresden/769112-venue-theater-wechselbad-groÃer-saal) in the
following code intended to add urls:-
$url->addchild("loc",$mainurl);
Please provide me with the solution to my problem as soon as possible and also
please let me know the changes which I should do in order to get urls in my xml
file.
Some of the urls are not added in $url->addchild("loc",$mainurl);
Test script:
---
addchild("loc",$mainurl); **/
$xmltext = "\nhttp://www.sitemaps.org/schemas/sitemap/0.9\";>";
$xmlobj = simplexml_load_string($xmltext);
/** Code to retrieve venue array **/
$venue = new record();
$venueArray=$venue->getAll();
/** End of the Code to retrieve venue array **/
foreach($venueArray as $venueD){
/** Code to retrieve Url from venue array **/
$mainurl
=$venue->getUrl(array("venueId"=>$venueD['id']));
/**
Example of the url generated
http://mysite.com/dresden/769112-venue-theater-wechselbad-groÃer-saal
**/
$url= $xmlobj->addChild("url");
$url->addchild("loc",$mainurl);
$url->addChild("lastmod",date('Y-m-d'));
$url->addChild("changefreq","daily");
$url->addChild("priority","0.9");
$fp=fopen('test.xml',"a");
fwrite($fp,$xmlobj->asXML());
fclose($fp);
}
?>
Expected result:
http://www.sitemaps.org/schemas/sitemap/0.9";>
http://mysite.com/dresden/769112-venue-theater-wechselbad-groÃer-
saal
2012-12-21
daily
0.9
Actual result:
--
http://www.sitemaps.org/schemas/sitemap/0.9";>
2012-12-21
daily
0.9
--
Edit this bug report at https://bugs.php.net/bug.php?id=63853&edit=1
Bug #63862 [Opn]: Passing by reference: func($a = $b);
Edit report at https://bugs.php.net/bug.php?id=63862&edit=1
ID: 63862
User updated by:bobwei9 at hotmail dot com
Reported by:bobwei9 at hotmail dot com
Summary:Passing by reference: func($a = $b);
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Mac OS X Mountain Lion
PHP Version:master-Git-2012-12-27 (Git)
Block user comment: N
Private report: N
New Comment:
I know how it works now, but I don't know if it is intended (It isn't
documented.)
Then I wish that the first variable $a = $b = $c; is passed by array.
Previous Comments:
[2012-12-31 22:06:57] mail+php at requinix dot net
FYI:
Expected behavior. The "value" of an assignment is just a value and not a
reference to a variable, just like how "true?$a:$b" is the value of $a and not
actually the variable $a.
I don't think it would be so difficult to change that behavior but I'm afraid
of
the consequences it might have.
There's also a more subtle change that would be required for your shorthand to
work. Assignment currently propagates the right-most operand: $a=$b=$c is
almost
equivalent* to $b=$c;$a=$c; and not $b=$c;$a=$b; Unless that changes as well
then
sort($array=[3,1,2]) would try to sort the [3,1,2] and not $array.
* $c is evaluated only once
[2012-12-27 16:57:06] bobwei9 at hotmail dot com
Description:
I don't know if this should be considered as a bug or as expected behaviour (=>
feature request).
When passing an assignment to a function which expects a variable as reference
like sort(), then an E_STRICT message is issued and nothing has changed.
What I want, is that a code like "sort($a = $b);" is executed in the same way
as "$a = $b; sort($a);".
This could help to reduce the number of little, unnecessary lines.
Test script:
---
php -r 'sort($array = [3,1,2]); var_dump($array);'
Expected result:
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
Actual result:
--
Strict Standards: Only variables should be passed by reference in Command line
code on line 1
array(3) {
[0]=>
int(3)
[1]=>
int(1)
[2]=>
int(2)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=63862&edit=1
[PHP-BUG] Req #63880 [NEW]: Implement xz compression
From: tobias at freiwuppertal dot de Operating system: Irrelevant PHP version: Irrelevant Package: *Compression related Bug Type: Feature/Change Request Bug description:Implement xz compression Description: http://php.net/manual/en/refs.compression.php ^ xz is not implemented yet, sadly. :-/ https://en.wikipedia.org/wiki/Xz The compression results are usually significantly better than those of bzip2. This feature request currently blocks another one at phpbb: http://tracker.phpbb.com/browse/PHPBB3-11300 -- Edit bug report at https://bugs.php.net/bug.php?id=63880&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63880&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63880&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63880&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63880&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63880&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63880&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63880&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63880&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63880&r=support Expected behavior: https://bugs.php.net/fix.php?id=63880&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63880&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63880&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63880&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63880&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63880&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63880&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63880&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63880&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63880&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63880&r=mysqlcfg
