[PHP-BUG] Bug #65848 [NEW]: output from php error
From: wisans at gmail dot com Operating system: Linux 2.6.32-279.el6.x86_64 PHP version: 5.5.4 Package: *General Issues Bug Type: Bug Bug description:output from php error Description: this error it happen random. i attach file you can see image output and some my source code in zip file. now i use ob_start to prevent this error i share file in https://www.dropbox.com/sh/3hckbmog2y1mtem/aM_6FkbqpC please help me -- Edit bug report at https://bugs.php.net/bug.php?id=65848&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65848&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=65848&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65848&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65848&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65848&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65848&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65848&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65848&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65848&r=support Expected behavior: https://bugs.php.net/fix.php?id=65848&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65848&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65848&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65848&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65848&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65848&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65848&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65848&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65848&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65848&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65848&r=mysqlcfg
Bug #64693 [Com]: Third argument ($initial) passed to array_reduce should be immutable.
Edit report at https://bugs.php.net/bug.php?id=64693&edit=1
ID: 64693
Comment by: a at b dot c dot de
Reported by:jdoane at vlacs dot org
Summary:Third argument ($initial) passed to array_reduce
should be immutable.
Status: Not a bug
Type: Bug
Package:Arrays related
Operating System: Ubuntu 12.04.02 LTS
PHP Version:5.3.24
Block user comment: N
Private report: N
New Comment:
"Normal passing semantics" refers not only to the pass-by-value semantics of
PHP, but also to many OO-based languages such as Java and C#: changing an
object's properties inside a function will change the properties of the object
- the object itself remains the same object and doesn't get cloned or replaced
in the process.
Of course, if you explicitly pass the object by reference as you do in your
sample code then the behaviour changes in a way similar to C#'s ref signature
modifier.
Previous Comments:
[2013-04-23 15:54:49] jdoane at vlacs dot org
So you're telling me that the inconsistent behavior is not due to the poor
implementation of array_reduce() but rather of PHP? So even though things by
name imply that a variable is immutable (hence $initial, you do know what
initial means, right?) that the resulting mutation will make it something other
than the initial value?
Thank you for clarifying that for me, but you leave me baffled as to your
reasoning why this seems like a good idea. Maybe it's not a bug, but it's
definitely not clean and consistent. Consider saying that a variable is an
"initial" value, you would think that it would remain an initial value, hence
implying the value (regardless of type) is immutable.
[2013-04-23 15:27:11] ni...@php.net
array_reduce uses the normal passing semantics. We do not document for every
function that it uses the normal passing semantics, because, well, they are the
same everywhere.
PHP never clones your objects unless you tell it to.
[2013-04-23 13:04:13] jdoane at vlacs dot org
The order of the expected output is backwards, I apologize.
It should be:
~$ php test.php
stdClass Object
(
[count] => 2
[maxlen] => 5
)
stdClass Object
(
[count] => 0
[maxlen] => 0
)
[2013-04-22 19:41:14] jdoane at vlacs dot org
Description:
When array_reduce is called with an object as the third argument, the variable
passed to said third argument will turn into the result of the array_reduce()
call. It feels like the object getting passed into array_reduce is not being
cloned and is being modified in place. Since all objects are passed as a
reference
it changes the "$initial" variable in the scope where array_reduce was called.
So either documentation needs to be updated that says that $initial gets set to
the return value when it is an object or this shouldn't happen to begin with as
it
appears that $initial should remain immutable for the duration of the
array_reduce() call.
Test script:
---
$array = (object)Array('foo', 'baraz');
$initial = (object)Array('count' => 0, 'maxlen' => 0);
$output = array_reduce($array, function(&$d, $item) {
if($d->maxlen < strlen($d)) { $d->maxlen = strlen($d); }
$d->count++;
return $d;
}
print_r($output);
print_r($initial);
Expected result:
~$ php test.php
stdClass Object
(
[count] => 0
[maxlen] => 0
)
stdClass Object
(
[count] => 2
[maxlen] => 5
)
Actual result:
--
~$ php test.php
stdClass Object
(
[count] => 2
[maxlen] => 5
)
stdClass Object
(
[count] => 2
[maxlen] => 5
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64693&edit=1
Bug #64755 [Com]: Only variables should be passed by reference
Edit report at https://bugs.php.net/bug.php?id=64755&edit=1
ID: 64755
Comment by: a at b dot c dot de
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:
For guy's example. Yes, your assumption is wrong; the suggestion 'that the type
of "$value = array()" is expression and not a variable' is correct. It's not a
variable, it's an assignment expression.
Previous Comments:
[2013-09-12 01:41:42] guy at syntheticwebapps dot com
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?
[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);...).
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=64755
--
Edit this bug report at https://bugs.php.net/bug.php?id=647
Bug #65845 [Opn]: Error when Zend Opcache Optimizer is fully enabled
Edit report at https://bugs.php.net/bug.php?id=65845&edit=1
ID: 65845
User updated by:bruno+php at ahennezel dot info
Reported by:bruno+php at ahennezel dot info
Summary:Error when Zend Opcache Optimizer is fully enabled
Status: Open
Type: Bug
-Package:optimizer
+Package:opcache
Operating System: Linux 3.11.2-1-ARCH
PHP Version:5.5.4
Block user comment: N
Private report: N
New Comment:
Wrong package : Opcache
Previous Comments:
[2013-10-06 18:10:34] bruno+php at ahennezel dot info
Typo : With opcache.optimization_level=0xffef the result is "value".
[2013-10-06 11:38:42] bruno+php at ahennezel dot info
Description:
With the SPIP CMS V3, the default optimization level
opcache.optimization_level=0x
and
opcache.optimization_level=0xffef
give different results.
Test script:
---
I dont know how to test directly in PHP, but here is a very short SPIP snippet
which brings out the problem. Put in the SPIP's sommaire.html skeleton :
#SET{var,value}
[(#GET{var})]
With opcache.optimization_level=0x the result is empty.
With opcache.optimization_level=0x the result is "value".
Expected result:
I expect the content "value"
Actual result:
--
The content is empty
--
Edit this bug report at https://bugs.php.net/bug.php?id=65845&edit=1
Req #65843 [Opn]: Impossibility to assign an object to a property upon declaration
Edit report at https://bugs.php.net/bug.php?id=65843&edit=1 ID: 65843 Updated by: ras...@php.net Reported by:funnyoz at hotmail dot fr Summary:Impossibility to assign an object to a property upon declaration Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Ubuntu 13.04 PHP Version:5.5.4 Block user comment: N Private report: N New Comment: This would force the definition of this class into the executor losing all the optimizations that go along with being able to fully define classes at compile-time. The performance impact of this would be significant so I don't see this happening anytime soon, if ever. Previous Comments: [2013-10-06 10:21:09] funnyoz at hotmail dot fr Description: Hello, This is a very important feature in OOP style, upon declaration, one might need to assign an object as a default value, this is currently possible for arrays or primitive types in PHP, but not for objects. Example : createAddress(); } ?> The above code respects the best practices of OOP, it even uses the Factory design pattern, yet in PHP it will fail because it can't be evaluated at compilation. Another simple example, say I've created a wrapper class for arrays, in order to organize the different array functions, the following thing will happen Instantiating a property in the constructor is not a good practice in object oriented programming : array = $array; //I no longer have an empty constructor, my constructor now have //parameters, not OOP recommended. //Many scripts using Reflection API may instantiate // this class without calling the constructor, hence having a null $array property. } } ?> This feature is a must in the next generation of PHP. Just think about it. Test script: --- array = $array; //I no longer have an empty constructor, my constructor now have //parameters, not OOP recommended. //Many scripts using Reflection API may instantiate // this class without calling the constructor, hence having a null $array property. } } ?> Expected result: Compiler's response : success :-) Actual result: -- Compiler's response : WTF did you type in line 20 column 12?? -- Edit this bug report at https://bugs.php.net/bug.php?id=65843&edit=1
Bug #65589 [Nab]: PHP Language BUG
Edit report at https://bugs.php.net/bug.php?id=65589&edit=1
ID: 65589
Updated by: ras...@php.net
Reported by:wwwgying at qq dot com
Summary:PHP Language BUG
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows/Mac/Linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
You should read this:
http://c-faq.com/expr/seqpoints.html
Just because your particular C compiler gave you 3,2, there is no guarantee
that another one will produce the same result for that code. This is well-known
and documented to be undefined in both C and PHP and you cannot rely on the
result of an expression like that.
Previous Comments:
[2013-10-06 09:44:02] gautam dot nishchal at gmail dot com
Yep, there's a bug, but way of expressing is wrong, expected output is 3,2 but
gives you 3,3
[2013-10-06 08:48:20] gautam dot nishchal at gmail dot com
Expected result is int(3) int(2) I suggest you to read about pre and post
increment / decrement :p
[2013-10-06 08:44:47] gautam dot nishchal at gmail dot com
And who tells the program gives int(3) int(3)? I just wrote a program in C
which gave me 3 and 2,
#include
int main()
{
int a, c;
a=1;
c=a+a+a++;
printf("%d\n",c);
a=1;
c=a+a++;
printf("%d", c);
}
This program prints 3 2 not 3 3
[2013-10-06 08:35:00] gautam dot nishchal at gmail dot com
I would like to say something to reporter, i think that's a post increment
expression which will give int(3) int(3). That's not bug...
[2013-08-30 20:45:11] ahar...@php.net
This is undefined behaviour in PHP, as in most languages with C-derived
syntaxes.
Mailing list discussion from last month:
http://marc.info/?t=13742793432&r=1&w=2
This is also documented, see example 1 on:
http://www.php.net/manual/en/language.operators.precedence.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=65589
--
Edit this bug report at https://bugs.php.net/bug.php?id=65589&edit=1
Bug #65844 [Opn->Nab]: array_search returns wrong last key if value it is 0
Edit report at https://bugs.php.net/bug.php?id=65844&edit=1
ID: 65844
Updated by: ni...@php.net
Reported by:marc-bennewitz at arcor dot de
Summary:array_search returns wrong last key if value it is 0
-Status: Open
+Status: Not a bug
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.5.4
Block user comment: N
Private report: N
New Comment:
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.
0 == 'unknown', so that's the element that will be found. If you want to use
=== comparison pass the $strict=true parameter.
Previous Comments:
[2013-10-06 11:01:00] marc-bennewitz at arcor dot de
Description:
array_search returns wrong last key (instead of false) if value it is 0
Test script:
---
$arr = array(
"ONE"=>1,
"TWO"=>2,
"THREE"=>3,
"FOUR"=>4,
"FIVE"=>5,
"SIX"=>6,
"SEVEN"=>7,
"EIGHT"=>8,
"NINE"=>9,
"ZERO"=>0
);
var_dump(array_search('unknown', $arr));
Expected result:
bool(false)
Actual result:
--
string(4) "ZERO"
--
Edit this bug report at https://bugs.php.net/bug.php?id=65844&edit=1
[PHP-BUG] Bug #65844 [NEW]: array_search returns wrong last key if value it is 0
From: marc-bennewitz at arcor dot de
Operating system: linux
PHP version: 5.5.4
Package: Arrays related
Bug Type: Bug
Bug description:array_search returns wrong last key if value it is 0
Description:
array_search returns wrong last key (instead of false) if value it is 0
Test script:
---
$arr = array(
"ONE"=>1,
"TWO"=>2,
"THREE"=>3,
"FOUR"=>4,
"FIVE"=>5,
"SIX"=>6,
"SEVEN"=>7,
"EIGHT"=>8,
"NINE"=>9,
"ZERO"=>0
);
var_dump(array_search('unknown', $arr));
Expected result:
bool(false)
Actual result:
--
string(4) "ZERO"
--
Edit bug report at https://bugs.php.net/bug.php?id=65844&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65844&r=trysnapshot54
Try a snapshot (PHP 5.5):
https://bugs.php.net/fix.php?id=65844&r=trysnapshot55
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65844&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65844&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65844&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65844&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65844&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65844&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65844&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65844&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65844&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65844&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65844&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65844&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65844&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65844&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65844&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65844&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65844&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65844&r=mysqlcfg
[PHP-BUG] Req #65843 [NEW]: Impossibility to assign an object to a property upon declaration
From: funnyoz at hotmail dot fr Operating system: Ubuntu 13.04 PHP version: 5.5.4 Package: Class/Object related Bug Type: Feature/Change Request Bug description:Impossibility to assign an object to a property upon declaration Description: Hello, This is a very important feature in OOP style, upon declaration, one might need to assign an object as a default value, this is currently possible for arrays or primitive types in PHP, but not for objects. Example : createAddress(); } ?> The above code respects the best practices of OOP, it even uses the Factory design pattern, yet in PHP it will fail because it can't be evaluated at compilation. Another simple example, say I've created a wrapper class for arrays, in order to organize the different array functions, the following thing will happen Instantiating a property in the constructor is not a good practice in object oriented programming : array = $array; //I no longer have an empty constructor, my constructor now have //parameters, not OOP recommended. //Many scripts using Reflection API may instantiate // this class without calling the constructor, hence having a null $array property. } } ?> This feature is a must in the next generation of PHP. Just think about it. Test script: --- array = $array; //I no longer have an empty constructor, my constructor now have //parameters, not OOP recommended. //Many scripts using Reflection API may instantiate // this class without calling the constructor, hence having a null $array property. } } ?> Expected result: Compiler's response : success :-) Actual result: -- Compiler's response : WTF did you type in line 20 column 12?? -- Edit bug report at https://bugs.php.net/bug.php?id=65843&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65843&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=65843&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65843&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65843&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65843&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65843&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65843&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65843&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65843&r=support Expected behavior: https://bugs.php.net/fix.php?id=65843&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65843&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65843&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65843&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65843&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65843&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65843&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65843&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65843&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65843&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65843&r=mysqlcfg
Bug #65589 [Com]: PHP Language BUG
Edit report at https://bugs.php.net/bug.php?id=65589&edit=1
ID: 65589
Comment by: gautam dot nishchal at gmail dot com
Reported by:wwwgying at qq dot com
Summary:PHP Language BUG
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows/Mac/Linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Yep, there's a bug, but way of expressing is wrong, expected output is 3,2 but
gives you 3,3
Previous Comments:
[2013-10-06 08:48:20] gautam dot nishchal at gmail dot com
Expected result is int(3) int(2) I suggest you to read about pre and post
increment / decrement :p
[2013-10-06 08:44:47] gautam dot nishchal at gmail dot com
And who tells the program gives int(3) int(3)? I just wrote a program in C
which gave me 3 and 2,
#include
int main()
{
int a, c;
a=1;
c=a+a+a++;
printf("%d\n",c);
a=1;
c=a+a++;
printf("%d", c);
}
This program prints 3 2 not 3 3
[2013-10-06 08:35:00] gautam dot nishchal at gmail dot com
I would like to say something to reporter, i think that's a post increment
expression which will give int(3) int(3). That's not bug...
[2013-08-30 20:45:11] ahar...@php.net
This is undefined behaviour in PHP, as in most languages with C-derived
syntaxes.
Mailing list discussion from last month:
http://marc.info/?t=13742793432&r=1&w=2
This is also documented, see example 1 on:
http://www.php.net/manual/en/language.operators.precedence.php
[2013-08-30 08:17:54] wwwgying at qq dot com
Description:
we will get int(3) int(3)
and the same code,php result is not the same with other program languages.
Test script:
---
Expected result:
int(3) int(3)
Actual result:
--
int(3) int(2)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65589&edit=1
Bug #65589 [Com]: PHP Language BUG
Edit report at https://bugs.php.net/bug.php?id=65589&edit=1
ID: 65589
Comment by: gautam dot nishchal at gmail dot com
Reported by:wwwgying at qq dot com
Summary:PHP Language BUG
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows/Mac/Linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Expected result is int(3) int(2) I suggest you to read about pre and post
increment / decrement :p
Previous Comments:
[2013-10-06 08:44:47] gautam dot nishchal at gmail dot com
And who tells the program gives int(3) int(3)? I just wrote a program in C
which gave me 3 and 2,
#include
int main()
{
int a, c;
a=1;
c=a+a+a++;
printf("%d\n",c);
a=1;
c=a+a++;
printf("%d", c);
}
This program prints 3 2 not 3 3
[2013-10-06 08:35:00] gautam dot nishchal at gmail dot com
I would like to say something to reporter, i think that's a post increment
expression which will give int(3) int(3). That's not bug...
[2013-08-30 20:45:11] ahar...@php.net
This is undefined behaviour in PHP, as in most languages with C-derived
syntaxes.
Mailing list discussion from last month:
http://marc.info/?t=13742793432&r=1&w=2
This is also documented, see example 1 on:
http://www.php.net/manual/en/language.operators.precedence.php
[2013-08-30 08:17:54] wwwgying at qq dot com
Description:
we will get int(3) int(3)
and the same code,php result is not the same with other program languages.
Test script:
---
Expected result:
int(3) int(3)
Actual result:
--
int(3) int(2)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65589&edit=1
Bug #65589 [Com]: PHP Language BUG
Edit report at https://bugs.php.net/bug.php?id=65589&edit=1
ID: 65589
Comment by: gautam dot nishchal at gmail dot com
Reported by:wwwgying at qq dot com
Summary:PHP Language BUG
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows/Mac/Linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
And who tells the program gives int(3) int(3)? I just wrote a program in C
which gave me 3 and 2,
#include
int main()
{
int a, c;
a=1;
c=a+a+a++;
printf("%d\n",c);
a=1;
c=a+a++;
printf("%d", c);
}
This program prints 3 2 not 3 3
Previous Comments:
[2013-10-06 08:35:00] gautam dot nishchal at gmail dot com
I would like to say something to reporter, i think that's a post increment
expression which will give int(3) int(3). That's not bug...
[2013-08-30 20:45:11] ahar...@php.net
This is undefined behaviour in PHP, as in most languages with C-derived
syntaxes.
Mailing list discussion from last month:
http://marc.info/?t=13742793432&r=1&w=2
This is also documented, see example 1 on:
http://www.php.net/manual/en/language.operators.precedence.php
[2013-08-30 08:17:54] wwwgying at qq dot com
Description:
we will get int(3) int(3)
and the same code,php result is not the same with other program languages.
Test script:
---
Expected result:
int(3) int(3)
Actual result:
--
int(3) int(2)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65589&edit=1
Bug #65589 [Com]: PHP Language BUG
Edit report at https://bugs.php.net/bug.php?id=65589&edit=1 ID: 65589 Comment by: gautam dot nishchal at gmail dot com Reported by:wwwgying at qq dot com Summary:PHP Language BUG Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Windows/Mac/Linux PHP Version:5.5.3 Block user comment: N Private report: N New Comment: I would like to say something to reporter, i think that's a post increment expression which will give int(3) int(3). That's not bug... Previous Comments: [2013-08-30 20:45:11] ahar...@php.net This is undefined behaviour in PHP, as in most languages with C-derived syntaxes. Mailing list discussion from last month: http://marc.info/?t=13742793432&r=1&w=2 This is also documented, see example 1 on: http://www.php.net/manual/en/language.operators.precedence.php [2013-08-30 08:17:54] wwwgying at qq dot com Description: we will get int(3) int(3) and the same code,php result is not the same with other program languages. Test script: --- Expected result: int(3) int(3) Actual result: -- int(3) int(2) -- Edit this bug report at https://bugs.php.net/bug.php?id=65589&edit=1
