Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #3476 > unrolled thread

simple session question

Back to article view | Back to comp.lang.php

Contents

  simple session question cerr <ron.eggler@gmail.com> - 2011-10-21 10:44 -0700
    Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-21 20:19 +0200
      Re: simple session question Jonathan Stein <jstein@image.dk> - 2011-10-21 20:51 +0200
        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-21 22:00 +0200
          Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-21 16:14 -0400
            Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 00:50 +0200
              Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-21 19:05 -0400
                Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 15:40 +0200
                  Re: simple session question Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-22 17:19 -0400
                    Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 22:56 +0100
                      Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 00:35 +0200
                      Re: simple session question Tim Streater <timstreater@greenbee.net> - 2011-10-22 23:43 +0100
                        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:56 +0200
                      Re: simple session question Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-22 19:29 -0400
                        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:54 +0200
                    Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 02:12 +0200
                      Re: simple session question Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-22 21:13 -0400
                        Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 08:44 +0100
                          Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 17:31 +0200
                            Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 17:18 +0100
                              Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 19:14 +0200
                                Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 18:16 +0100
                        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 19:00 +0200
                          Re: simple session question Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-23 15:28 -0400
                      Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-22 23:03 -0400
                        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 19:06 +0200
                          Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-23 14:35 -0400
              Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 00:32 +0100
                Re: simple session question Luuk <Luuk@invalid.lan> - 2011-10-22 12:01 +0200
                  Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 15:27 +0100
                    Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 15:37 +0100
                      Re: simple session question Luuk <Luuk@invalid.lan> - 2011-10-22 17:08 +0200
                        OT: and even in Dart .........Re: simple session question Luuk <Luuk@invalid.lan> - 2011-10-22 17:17 +0200
                          Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 16:54 +0100
                            Re: OT: and even in Dart .........Re: simple session question Luuk <Luuk@invalid.lan> - 2011-10-22 18:47 +0200
                              Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 19:34 +0200
                                Re: OT: and even in Dart .........Re: simple session question Norman Peelman <npeelmandog@cfl.rr.com> - 2011-10-22 16:08 -0400
                                  Re: OT: and even in Dart .........Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-22 16:28 -0400
                                    Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:39 +0200
                                    Re: OT: and even in Dart .........Re: simple session question Norman Peelman <npeelmandog@cfl.rr.com> - 2011-10-22 22:40 -0400
                                      Re: OT: and even in Dart .........Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-22 23:05 -0400
                                  Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 22:52 +0100
                                    Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:25 +0200
                                      Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 08:41 +0100
                                  Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 00:56 +0200
                                    Re: OT: and even in Dart .........Re: simple session question Norman Peelman <npeelmandog@cfl.rr.com> - 2011-10-22 22:52 -0400
                                      Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 17:12 +0200
                                    Re: OT: and even in Dart .........Re: simple session question Tim Streater <timstreater@greenbee.net> - 2011-10-23 09:39 +0100
                                      Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 09:40 +0100
                                        Re: OT: and even in Dart .........Re: simple session question Tim Streater <timstreater@greenbee.net> - 2011-10-23 09:43 +0100
                                  Re: OT: and even in Dart .........Re: simple session question "Peter H. Coffin" <hellsop@ninehells.com> - 2011-11-05 15:04 -0500
                                Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-22 22:47 +0100
                                  Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 01:22 +0200
                                    Re: OT: and even in Dart .........Re: simple session question The Natural Philosopher <tnp@invalid.invalid> - 2011-10-23 08:40 +0100
                                      Re: OT: and even in Dart .........Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-23 17:04 +0200
                            Re: OT: and even in Dart .........Re: simple session question "Peter H. Coffin" <hellsop@ninehells.com> - 2011-11-05 15:00 -0500
                Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 15:39 +0200
      Re: simple session question cerr <ron.eggler@gmail.com> - 2011-10-21 14:43 -0700
        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 00:47 +0200
        Re: simple session question Jerry Stuckle <jstucklex@attglobal.net> - 2011-10-21 19:06 -0400
      Re: simple session question cerr <ron.eggler@gmail.com> - 2011-10-21 14:17 -0700
        Re: simple session question Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-10-22 15:50 +0200
      Re: simple session question Denis McMahon <denismfmcmahon@gmail.com> - 2011-10-23 15:47 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#3545

The Natural Philosopher schrieb:

> cat test.c
> #include <stdio.h>
> main()
> {
> int foo,bar;
> foo=0;
> bar=(foo++);
> printf("%d\n",bar);
> }
> $ make test
> cc     test.c   -o test
> $./test
> 0
> 
> --------------------
> 
> $ cat test.c
> #include <stdio.h>
> main()
> {
> int foo,bar;
> foo=0;
> foo=(foo++);
> printf("%d\n",foo);
> }
> $ make test
> cc     test.c   -o test
> $ ./test
> 1
> 
> Looks like its stepping off into 'indeterminate behaviour'

So the lesson to be learnt here is what we all already knew: Don't do 
$foo = $foo++.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3546

Thomas Mlynarczyk wrote:
> The Natural Philosopher schrieb:
> 
>> cat test.c
>> #include <stdio.h>
>> main()
>> {
>> int foo,bar;
>> foo=0;
>> bar=(foo++);
>> printf("%d\n",bar);
>> }
>> $ make test
>> cc     test.c   -o test
>> $./test
>> 0
>>
>> --------------------
>>
>> $ cat test.c
>> #include <stdio.h>
>> main()
>> {
>> int foo,bar;
>> foo=0;
>> foo=(foo++);
>> printf("%d\n",foo);
>> }
>> $ make test
>> cc     test.c   -o test
>> $ ./test
>> 1
>>
>> Looks like its stepping off into 'indeterminate behaviour'
> 
> So the lesson to be learnt here is what we all already knew: Don't do 
> $foo = $foo++.
> 
well being the worst typist ever, I never would as

$foo++;

is shorter.;)

> Greetings,
> Thomas
> 

[toc] | [prev] | [next] | [standalone]

#3543

Richard Damon schrieb:

> The issue is C is that there is a general rule (to allow optimizations) 
> that defines the behavior to be undefined if an expression causes a 
> variable to be written to twice, or have a read from and write to (where 
> the read from is not needed to determine the value to write to) without 
> an intervening sequence point, like the end of an expression.

So basically, it boils down to "programmer" vs. "compiler": The 
programmer would like to have everything defined clearly, because 
anything "undefined" simply means (s)he cannot use that construct. The 
compiler, on the other hand, can work the better, the fewer restrictions 
there are, and thus "welcomes" anything left undefined. And C focuses 
more on the compiler, while PHP focuses more on the programmer.

> The statement x = x++; has two different writes to x, so we meet the 
> requirement for undefined behavior. Not also that C does not limit when 
> the ++ part happens, only that this side effect will finish by the next 
> sequence point.

So in C, the statement x = x++ is regarded "as a whole" and the compiler 
can do anything with it as long as certain constraints are observed, 
while PHP, being a higher level language than C, must have all the tiny 
internal steps well defined.

> Part of the problem with this example is that it is a bit to simple, and 
> that simplicity hides some of the issues. Let us make the expression 
> just slightly more complicated to make it cleared. Let us use x = 5*x++;

If I have understood you correctly, this would be

In PHP:
[1] $tmp = $x;
[2] $x = $x + 1;
[3] $tmp = 5 * $tmp;
[4] $x = $tmp;
In exactly that order (or maybe [2] and [3] swapped as it would make no 
difference).

In C:
[TODO] RHS = 5 * (value of x before increment)
[TODO] increment x
[TODO] LHS = RHS
With the only restriction on the order being that the third item must 
necessarily come after the first and it's up to the compiler to choose.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3550

On 10/23/11 1:00 PM, Thomas Mlynarczyk wrote:
> Richard Damon schrieb:
>
>> The issue is C is that there is a general rule (to allow
>> optimizations) that defines the behavior to be undefined if an
>> expression causes a variable to be written to twice, or have a read
>> from and write to (where the read from is not needed to determine the
>> value to write to) without an intervening sequence point, like the end
>> of an expression.
>
> So basically, it boils down to "programmer" vs. "compiler": The
> programmer would like to have everything defined clearly, because
> anything "undefined" simply means (s)he cannot use that construct. The
> compiler, on the other hand, can work the better, the fewer restrictions
> there are, and thus "welcomes" anything left undefined. And C focuses
> more on the compiler, while PHP focuses more on the programmer.
>
>> The statement x = x++; has two different writes to x, so we meet the
>> requirement for undefined behavior. Not also that C does not limit
>> when the ++ part happens, only that this side effect will finish by
>> the next sequence point.
>
> So in C, the statement x = x++ is regarded "as a whole" and the compiler
> can do anything with it as long as certain constraints are observed,
> while PHP, being a higher level language than C, must have all the tiny
> internal steps well defined.
>
>> Part of the problem with this example is that it is a bit to simple,
>> and that simplicity hides some of the issues. Let us make the
>> expression just slightly more complicated to make it cleared. Let us
>> use x = 5*x++;
>
> If I have understood you correctly, this would be
>
> In PHP:
> [1] $tmp = $x;
> [2] $x = $x + 1;
> [3] $tmp = 5 * $tmp;
> [4] $x = $tmp;
> In exactly that order (or maybe [2] and [3] swapped as it would make no
> difference).
>
> In C:
> [TODO] RHS = 5 * (value of x before increment)
> [TODO] increment x
> [TODO] LHS = RHS
> With the only restriction on the order being that the third item must
> necessarily come after the first and it's up to the compiler to choose.
>
> Greetings,
> Thomas
>

Actually, both have the same basic steps (in principle)

(1) temp1 = x
(2) temp2 = x
(3) x = temp2 + 1
(4) temp3 = 5 * temp2
(5) x = temp3

(1 & 2 may be redundant and combined)
2,3 are the x++, 1,4,5 is the x = 5*x
by necessity we need the following order (can't use a value before it is 
available)

1 -> 4 -> 5
2 -> 3
and by the definition of x++, 1 -> 3

PHP appears to define the order to be

1,2 -> 3 -> 4 -> 5

which means the increment of x is done tied to the fetching of the value 
of x.

C places no additional restrictions on the order of the parts.

In particular, 3 can come before or after 5, and if 3 is after 5, 2 can 
be before or after 5.

[toc] | [prev] | [next] | [standalone]

#3526

On 10/22/2011 8:12 PM, Thomas Mlynarczyk wrote:
> Richard Damon schrieb:
>
>> I suspect that there is a difference between the execution model of
>> C/C++ and PHP here, do in part to the fact that C/C++ is (normally) a
>> compiled language with the goal of allowing the compiler to generate
>> as efficient of code as possible, while PHP is designed as a
>> interpreted language.
>
> Hm. But PHP is written in C, so I would assume it to just follow C here.
>
>> x = x; /* perform the = */
>> x = x+1; /* perform the ++ */
>
> That could be further optimized by dropping the x = x. But here the
> assignment seems to have a higher precedence than the increment.
>
>> temp = x;
>> x = x+1;
>> ... do what ever with temp
>>
>> Which being an interpreted language makes some sense, why put off
>> doing something, and recording somewhere that you need to do it, when
>> you can do it now, the possible savings that C might have been able to
>> make, get swamped by the other overhead in PHP.
>
> Now I wonder why x = x++ is undefined in C. If it was defined to be a no
> op as it behaves in PHP, then it could be optimized away completely.
>
> Greetings,
> Thomas
>

Because it's not a noop.  The language only defined the order of 
operator evaluation - not operand evaluation.  Some C compilers will 
return 0, others will return 1.

The problem here is you are setting the value in the operand ($!foo) 
twice in the same expression.  Results of such operations is always 
undefined in C.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#3544

Jerry Stuckle schrieb:

> The problem here is you are setting the value in the operand ($!foo) 
> twice in the same expression.  Results of such operations is always 
> undefined in C.

In other words: if it were two different variables, like a = b++, there 
would be no problem and the result would always be the same, so the 
compiler can "choose" how it will do the work. And if there is then a 
case where the two variables are the same, the compiler will just "do as 
usual", but in this case the result will depend on how it does it.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3549

On 10/23/2011 1:06 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> The problem here is you are setting the value in the operand ($!foo)
>> twice in the same expression. Results of such operations is always
>> undefined in C.
>
> In other words: if it were two different variables, like a = b++, there
> would be no problem and the result would always be the same, so the
> compiler can "choose" how it will do the work. And if there is then a
> case where the two variables are the same, the compiler will just "do as
> usual", but in this case the result will depend on how it does it.
>
> Greetings,
> Thomas
>

Exactly.  When there are two variables, it doesn't matter whether the 
actual increment of b is done before or after the assignment of the old 
value into a.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#3487

Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
> 
>>> $foo = 0;
>>> $foo = $foo++;
>>>
>>> is basically equivalent to
>>>
>>> $foo = 0;
>>> $tmp = $foo;
>>> $foo = $foo + 1;
>>> $foo = $tmp;
>>
>> The behavior is correct, and can be relied upon 100%.
> 
> Is that mentioned somewhere in the manual? Anyway, to me, $foo = $foo++ 
> looks like asking for trouble.
> 

Why?

try $foo=($foo++);

But actually, why not just

$foo+=1;

or even

$foo++;

> Greetings,
> Thomas
> 

[toc] | [prev] | [next] | [standalone]

#3488

On 22-10-2011 01:32, The Natural Philosopher wrote:
> try $foo=($foo++);
>
> But actually, why not just
>
> $foo+=1;

Because they differ?

$ php -r ' $foo=0; $foo=$foo++;  print $foo."\n";'
0
$ php -r ' $foo=0; $foo=($foo++);  print $foo."\n";'
0
$ php -r ' $foo=0; $foo++;  print $foo."\n";'
1
$


-- 
Luuk

[toc] | [prev] | [next] | [standalone]

#3492

Luuk wrote:
> On 22-10-2011 01:32, The Natural Philosopher wrote:
>> try $foo=($foo++);
>>
>> But actually, why not just
>>
>> $foo+=1;
> 
> Because they differ?
> 
> $ php -r ' $foo=0; $foo=$foo++;  print $foo."\n";'
> 0
> $ php -r ' $foo=0; $foo=($foo++);  print $foo."\n";'
> 0

That is surely a bug..


> $ php -r ' $foo=0; $foo++;  print $foo."\n";'
> 1
> $
> 
> 

[toc] | [prev] | [next] | [standalone]

#3493

The Natural Philosopher wrote:
> Luuk wrote:
>> On 22-10-2011 01:32, The Natural Philosopher wrote:
>>> try $foo=($foo++);
>>>
>>> But actually, why not just
>>>
>>> $foo+=1;
>>
>> Because they differ?
>>
>> $ php -r ' $foo=0; $foo=$foo++;  print $foo."\n";'
>> 0
>> $ php -r ' $foo=0; $foo=($foo++);  print $foo."\n";'
>> 0
> 
> That is surely a bug..
> 

viz

~$ cat test.c
#include <stdio.h>
main()
{
int foo;
foo=0;
foo=(foo++);
printf("%d\n",foo);
}
~$ ./test
1


I thought PHP followed C operator precedence exactly..


> 
>> $ php -r ' $foo=0; $foo++;  print $foo."\n";'
>> 1
>> $
>>
>>

[toc] | [prev] | [next] | [standalone]

#3494

On 22-10-2011 16:37, The Natural Philosopher wrote:
> The Natural Philosopher wrote:
>> Luuk wrote:
>>> On 22-10-2011 01:32, The Natural Philosopher wrote:
>>>> try $foo=($foo++);
>>>>
>>>> But actually, why not just
>>>>
>>>> $foo+=1;
>>>
>>> Because they differ?
>>>
>>> $ php -r ' $foo=0; $foo=$foo++; print $foo."\n";'
>>> 0
>>> $ php -r ' $foo=0; $foo=($foo++); print $foo."\n";'
>>> 0
>>
>> That is surely a bug..
>>
>
> viz
>
> ~$ cat test.c
> #include <stdio.h>
> main()
> {
> int foo;
> foo=0;
> foo=(foo++);
> printf("%d\n",foo);
> }
> ~$ ./test
> 1
>
>
> I thought PHP followed C operator precedence exactly..
>
>

it seems to follow PERL

$ perl -e '$foo=0; $foo=$foo++; print $foo."\n";'
0
$ perl -e '$foo=0; $foo=($foo++); print $foo."\n";'
0
$ perl -e '$foo=0; $foo++; print $foo."\n";'
1
$


>>
>>> $ php -r ' $foo=0; $foo++; print $foo."\n";'
>>> 1
>>> $
>>>
>>>


-- 
Luuk

[toc] | [prev] | [next] | [standalone]

#3495 — OT: and even in Dart .........Re: simple session question

On 22-10-2011 17:08, Luuk wrote:
> On 22-10-2011 16:37, The Natural Philosopher wrote:
>> The Natural Philosopher wrote:
>>> Luuk wrote:
>>>> On 22-10-2011 01:32, The Natural Philosopher wrote:
>>>>> try $foo=($foo++);
>>>>>
>>>>> But actually, why not just
>>>>>
>>>>> $foo+=1;
>>>>
>>>> Because they differ?
>>>>
>>>> $ php -r ' $foo=0; $foo=$foo++; print $foo."\n";'
>>>> 0
>>>> $ php -r ' $foo=0; $foo=($foo++); print $foo."\n";'
>>>> 0
>>>
>>> That is surely a bug..
>>>
>>
>> viz
>>
>> ~$ cat test.c
>> #include <stdio.h>
>> main()
>> {
>> int foo;
>> foo=0;
>> foo=(foo++);
>> printf("%d\n",foo);
>> }
>> ~$ ./test
>> 1
>>
>>
>> I thought PHP followed C operator precedence exactly..
>>
>>
>
> it seems to follow PERL
>
> $ perl -e '$foo=0; $foo=$foo++; print $foo."\n";'
> 0
> $ perl -e '$foo=0; $foo=($foo++); print $foo."\n";'
> 0
> $ perl -e '$foo=0; $foo++; print $foo."\n";'
> 1
> $
>
>

see: http://www.dartlang.org

main() {
   int foo=0;
   foo=foo++;
   print('First test: ${foo}');

   foo=0;
   foo=(foo++);
   print('Second test: ${foo}');

   foo=0;
   foo++;
   print('Third test: ${foo}');

}

which gives:
First test: 0
Second test: 0
Third test: 1


-- 
Luuk

[toc] | [prev] | [next] | [standalone]

#3496 — Re: OT: and even in Dart .........Re: simple session question

Luuk wrote:
> On 22-10-2011 17:08, Luuk wrote:
>> On 22-10-2011 16:37, The Natural Philosopher wrote:
>>> The Natural Philosopher wrote:
>>>> Luuk wrote:
>>>>> On 22-10-2011 01:32, The Natural Philosopher wrote:
>>>>>> try $foo=($foo++);
>>>>>>
>>>>>> But actually, why not just
>>>>>>
>>>>>> $foo+=1;
>>>>>
>>>>> Because they differ?
>>>>>
>>>>> $ php -r ' $foo=0; $foo=$foo++; print $foo."\n";'
>>>>> 0
>>>>> $ php -r ' $foo=0; $foo=($foo++); print $foo."\n";'
>>>>> 0
>>>>
>>>> That is surely a bug..
>>>>
>>>
>>> viz
>>>
>>> ~$ cat test.c
>>> #include <stdio.h>
>>> main()
>>> {
>>> int foo;
>>> foo=0;
>>> foo=(foo++);
>>> printf("%d\n",foo);
>>> }
>>> ~$ ./test
>>> 1
>>>
>>>
>>> I thought PHP followed C operator precedence exactly..
>>>
>>>
>>
>> it seems to follow PERL
>>
>> $ perl -e '$foo=0; $foo=$foo++; print $foo."\n";'
>> 0
>> $ perl -e '$foo=0; $foo=($foo++); print $foo."\n";'
>> 0
>> $ perl -e '$foo=0; $foo++; print $foo."\n";'
>> 1
>> $
>>
>>
> 
> see: http://www.dartlang.org
> 
> main() {
>   int foo=0;
>   foo=foo++;
>   print('First test: ${foo}');
> 
>   foo=0;
>   foo=(foo++);
>   print('Second test: ${foo}');
> 
>   foo=0;
>   foo++;
>   print('Third test: ${foo}');
> 
> }
> 
> which gives:
> First test: 0
> Second test: 0
> Third test: 1
> 
> 

still a bug in PHP where

"Parentheses may be used to force precedence, if necessary. For 
instance: (1 + 5) * 3 evaluates to 18"

(from the manual)

I THOUGHT the general rule was that the value of (entity) was always the 
FINAL value after ALL internal operations had been carried out.

Agreed its a crappy way to code, which is probably why no one has 
noticed it.

[toc] | [prev] | [next] | [standalone]

#3499 — Re: OT: and even in Dart .........Re: simple session question

On 22-10-2011 17:54, The Natural Philosopher wrote:
> Luuk wrote:
>> On 22-10-2011 17:08, Luuk wrote:
>>> On 22-10-2011 16:37, The Natural Philosopher wrote:
>>>> The Natural Philosopher wrote:
>>>>> Luuk wrote:
>>>>>> On 22-10-2011 01:32, The Natural Philosopher wrote:
>>>>>>> try $foo=($foo++);
>>>>>>>
>>>>>>> But actually, why not just
>>>>>>>
>>>>>>> $foo+=1;
>>>>>>
>>>>>> Because they differ?
>>>>>>
>>>>>> $ php -r ' $foo=0; $foo=$foo++; print $foo."\n";'
>>>>>> 0
>>>>>> $ php -r ' $foo=0; $foo=($foo++); print $foo."\n";'
>>>>>> 0
>>>>>
>>>>> That is surely a bug..
>>>>>
>>>>
>>>> viz
>>>>
>>>> ~$ cat test.c
>>>> #include <stdio.h>
>>>> main()
>>>> {
>>>> int foo;
>>>> foo=0;
>>>> foo=(foo++);
>>>> printf("%d\n",foo);
>>>> }
>>>> ~$ ./test
>>>> 1
>>>>
>>>>
>>>> I thought PHP followed C operator precedence exactly..
>>>>
>>>>
>>>
>>> it seems to follow PERL
>>>
>>> $ perl -e '$foo=0; $foo=$foo++; print $foo."\n";'
>>> 0
>>> $ perl -e '$foo=0; $foo=($foo++); print $foo."\n";'
>>> 0
>>> $ perl -e '$foo=0; $foo++; print $foo."\n";'
>>> 1
>>> $
>>>
>>>
>>
>> see: http://www.dartlang.org
>>
>> main() {
>> int foo=0;
>> foo=foo++;
>> print('First test: ${foo}');
>>
>> foo=0;
>> foo=(foo++);
>> print('Second test: ${foo}');
>>
>> foo=0;
>> foo++;
>> print('Third test: ${foo}');
>>
>> }
>>
>> which gives:
>> First test: 0
>> Second test: 0
>> Third test: 1
>>
>>
>
> still a bug in PHP where
>
> "Parentheses may be used to force precedence, if necessary. For
> instance: (1 + 5) * 3 evaluates to 18"
>
> (from the manual)
>
> I THOUGHT the general rule was that the value of (entity) was always the
> FINAL value after ALL internal operations had been carried out.
>
> Agreed its a crappy way to code, which is probably why no one has
> noticed it.

i did send a bug-report:
https://bugs.php.net/bug.php?id=60114

-- 
Luuk

[toc] | [prev] | [next] | [standalone]

#3500 — Re: OT: and even in Dart .........Re: simple session question

Luuk schrieb:
> i did send a bug-report:
> https://bugs.php.net/bug.php?id=60114

I do not see any bug here. I was confused because it's a crappy way to 
code, but it's clear why it works the way it does:

$foo = 0;
$foo = $foo++;

is definitely identical to

$foo = 0;
$foo = ($foo++);

since ++ has higher precedence than =. In fact, ($foo = $foo)++ does 
rightfully throw a parse error, since you can only increment a variable, 
not an expression.

As mentioned before in this thread, the above code is equivalent to

$foo = 0;
$tmp = $foo;     // $foo++ yields the previous value, which is 0
$foo = $foo + 1; // then $foo is incremented...
$foo = $tmp;     // ...and then re-assigned the old value

It's the exact same procedure as it would be with $foo = $bar++.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3505 — Re: OT: and even in Dart .........Re: simple session question

On 10/22/2011 01:34 PM, Thomas Mlynarczyk wrote:
> Luuk schrieb:
>> i did send a bug-report:
>> https://bugs.php.net/bug.php?id=60114
>
> I do not see any bug here. I was confused because it's a crappy way to
> code, but it's clear why it works the way it does:
>
> $foo = 0;
> $foo = $foo++;
>
> is definitely identical to
>
> $foo = 0;
> $foo = ($foo++);
>
> since ++ has higher precedence than =. In fact, ($foo = $foo)++ does
> rightfully throw a parse error, since you can only increment a variable,
> not an expression.
>
> As mentioned before in this thread, the above code is equivalent to
>
> $foo = 0;
> $tmp = $foo; // $foo++ yields the previous value, which is 0
> $foo = $foo + 1; // then $foo is incremented...
> $foo = $tmp; // ...and then re-assigned the old value
>
> It's the exact same procedure as it would be with $foo = $bar++.
>
> Greetings,
> Thomas
>

No they are not the same.

$foo = 0;
$foo = $foo++;

It should be equivalent to:

$foo = 0;        // 0
$foo = $foo;     // 0 = 0
$foo = $foo + 1; // 0 = (0 + 1)

$foo++ means that the variable is to be incremented after the variable 
is accessed. Something is clobbering that increment.

++$foo means that the variable is to be incremented piror to the 
variable being accessed. Works as expected.


   Haven't seen the source code but there must be some temporary 
variable that's getting clobbered for the $foo++ example.


-- 
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

[toc] | [prev] | [next] | [standalone]

#3506 — Re: OT: and even in Dart .........Re: simple session question

On 10/22/2011 4:08 PM, Norman Peelman wrote:
> On 10/22/2011 01:34 PM, Thomas Mlynarczyk wrote:
>> Luuk schrieb:
>>> i did send a bug-report:
>>> https://bugs.php.net/bug.php?id=60114
>>
>> I do not see any bug here. I was confused because it's a crappy way to
>> code, but it's clear why it works the way it does:
>>
>> $foo = 0;
>> $foo = $foo++;
>>
>> is definitely identical to
>>
>> $foo = 0;
>> $foo = ($foo++);
>>
>> since ++ has higher precedence than =. In fact, ($foo = $foo)++ does
>> rightfully throw a parse error, since you can only increment a variable,
>> not an expression.
>>
>> As mentioned before in this thread, the above code is equivalent to
>>
>> $foo = 0;
>> $tmp = $foo; // $foo++ yields the previous value, which is 0
>> $foo = $foo + 1; // then $foo is incremented...
>> $foo = $tmp; // ...and then re-assigned the old value
>>
>> It's the exact same procedure as it would be with $foo = $bar++.
>>
>> Greetings,
>> Thomas
>>
>
> No they are not the same.
>
> $foo = 0;
> $foo = $foo++;
>
> It should be equivalent to:
>
> $foo = 0; // 0
> $foo = $foo; // 0 = 0
> $foo = $foo + 1; // 0 = (0 + 1)
>
> $foo++ means that the variable is to be incremented after the variable
> is accessed. Something is clobbering that increment.
>
> ++$foo means that the variable is to be incremented piror to the
> variable being accessed. Works as expected.
>
>
> Haven't seen the source code but there must be some temporary variable
> that's getting clobbered for the $foo++ example.
>
>

Actually, I take my previous statement about the behavior being defined 
back.  Officially in C/C++, the results of this operation is undefined.

Precedence and associativity define the order in which operators are 
processed.  But the order of operand processing is not defined.

For

$foo = $foo++;

we have the same operand ($foo) being set twice.  The $foo++ will return 
0, and this value will be assigned into $foo.

But what is NOT defined is whether the assignment will occur before or 
after the value of $foo is actually incremented.  Either is possible.

Now in the case of

$foo = ($foo++);

The results are different, but they are still undefined.

In the first case the increment is obviously performed before the 
assignment (although the assignment correctly uses the pre-increment value).

In the second case it looks like the assignment is still using the 
pre-increment value, but the increment is done after the assignment.

Since the results are undefined, both are correct (or incorrect, as you 
may look at it), and may change with changes to the interpreter (or 
potentially the same version on different OS's).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#3519 — Re: OT: and even in Dart .........Re: simple session question

Jerry Stuckle schrieb:
> But what is NOT defined is whether the assignment will occur before or 
> after the value of $foo is actually incremented.  Either is possible.

Yes, that was exactly what had confused me at first. But now I am 
convinced that the most reasonable assumption is to increment at the 
earliest possible moment, i.e. immediately after the result of the 
expression $foo++ has been determined and before doing anything else. 
After all, the RHS must be evaluated completely (including any side 
effects this evaluation may have), before the result can be assigned to 
the LHS. And wouldn't this also be the most simple implementation of the 
evaluation algorithm? And it would allow for better optimization: the 
statement $foo = $foo++; would be equivalent to a no op.

Greetings,
Thomas


-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#3524 — Re: OT: and even in Dart .........Re: simple session question

On 10/22/2011 04:28 PM, Jerry Stuckle wrote:
> On 10/22/2011 4:08 PM, Norman Peelman wrote:
>> On 10/22/2011 01:34 PM, Thomas Mlynarczyk wrote:
>>> Luuk schrieb:
>>>> i did send a bug-report:
>>>> https://bugs.php.net/bug.php?id=60114
>>>
>>> I do not see any bug here. I was confused because it's a crappy way to
>>> code, but it's clear why it works the way it does:
>>>
>>> $foo = 0;
>>> $foo = $foo++;
>>>
>>> is definitely identical to
>>>
>>> $foo = 0;
>>> $foo = ($foo++);
>>>
>>> since ++ has higher precedence than =. In fact, ($foo = $foo)++ does
>>> rightfully throw a parse error, since you can only increment a variable,
>>> not an expression.
>>>
>>> As mentioned before in this thread, the above code is equivalent to
>>>
>>> $foo = 0;
>>> $tmp = $foo; // $foo++ yields the previous value, which is 0
>>> $foo = $foo + 1; // then $foo is incremented...
>>> $foo = $tmp; // ...and then re-assigned the old value
>>>
>>> It's the exact same procedure as it would be with $foo = $bar++.
>>>
>>> Greetings,
>>> Thomas
>>>
>>
>> No they are not the same.
>>
>> $foo = 0;
>> $foo = $foo++;
>>
>> It should be equivalent to:
>>
>> $foo = 0; // 0
>> $foo = $foo; // 0 = 0
>> $foo = $foo + 1; // 0 = (0 + 1)
>>
>> $foo++ means that the variable is to be incremented after the variable
>> is accessed. Something is clobbering that increment.
>>
>> ++$foo means that the variable is to be incremented piror to the
>> variable being accessed. Works as expected.
>>
>>
>> Haven't seen the source code but there must be some temporary variable
>> that's getting clobbered for the $foo++ example.
>>
>>
>
> Actually, I take my previous statement about the behavior being defined
> back. Officially in C/C++, the results of this operation is undefined.
>
> Precedence and associativity define the order in which operators are
> processed. But the order of operand processing is not defined.
>
> For
>
> $foo = $foo++;
>
> we have the same operand ($foo) being set twice. The $foo++ will return
> 0, and this value will be assigned into $foo.
>
> But what is NOT defined is whether the assignment will occur before or
> after the value of $foo is actually incremented. Either is possible.
>
> Now in the case of
>
> $foo = ($foo++);
>
> The results are different, but they are still undefined.
>
> In the first case the increment is obviously performed before the
> assignment (although the assignment correctly uses the pre-increment
> value).
>
> In the second case it looks like the assignment is still using the
> pre-increment value, but the increment is done after the assignment.
>
> Since the results are undefined, both are correct (or incorrect, as you
> may look at it), and may change with changes to the interpreter (or
> potentially the same version on different OS's).
>

   The problem seems to be that the post increment is being overwritten 
as if:

$foo = 0;
$tmp = $foo;
$foo = $foo + 1;
$foo = $tmp;

Which I think someone else may have said.

-- 
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.php

csiph-web