php-general Digest 3 Oct 2009 02:00:29 -0000 Issue 6370
Topics (messages 298477 through 298504):
Re: Parse Question Using list()
298477 by: Gerardo Benitez
Re: Self-Process php forms or not?
298478 by: MEM
298480 by: tedd
298481 by: tedd
298483 by: MEM
298484 by: tedd
298485 by: Ben Dunlap
298495 by: Manuel Lemos
298496 by: Manuel Lemos
298499 by: Manuel Lemos
Re: Curl output
298479 by: Ashley Sheridan
Re: PHP/MySQL Superstars
298482 by: tedd
Whacky increment/assignment logic with $foo++ vs ++$foo
298486 by: Daevid Vincent
298487 by: Ben Dunlap
298488 by: Robert Cummings
298489 by: Tommy Pham
298490 by: Daevid Vincent
298491 by: Ben Dunlap
298492 by: Daniel Brown
298493 by: Daniel Brown
298494 by: Ben Dunlap
298497 by: Ben Dunlap
298498 by: Ben Dunlap
298500 by: Daevid Vincent
298501 by: Mari Masuda
298502 by: Ben Dunlap
298503 by: Joost
Finding out DST with PHP
298504 by: Rohit Sodhia
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
>
> Use the tool that PHP provides for such problems.
>
> http://php.net/fgetcsv
fgetcsv is very useful, here a example:
<?php
$row = 1;
/* load file*/
$handle = fopen("log.csv", "r");
/* read line by line */
while (($data = fgetcsv($handle, 1000, ",")) !== FALSE) {
$num = count($data);
echo "<p> $num fields in line $row: <br /></p>\n";
$row++;
for ($c=0; $c < $num; $c++) {
echo $data[$c] . "<br />\n";
}
}
fclose($handle);
?>
--
Gerardo Benitez
--- End Message ---
--- Begin Message ---
I want to apologize to you all. I have mentioned two things on the same
basket, but it was not appropriate. Since a confirmation page is not the
same thing as a success page.
Let's forget about the confirmation page, since it's not required.
I'm now understanding that even if the form is submitted to self, we can
still use a redirect to a "success_message_page.php". However, we must do
this redirect, AFTER the form has submitted to himself. It's the only thing
that we have to pay attention here, correct?
Since we are not dealing with a confirmation page, or a multi-step form, the
hidden field isn't necessary.
It's this correct assumptions?
Please advice,
Regards,
Márcio
> -----Original Message-----
> From: kranthi [mailto:[email protected]]
> Sent: sexta-feira, 2 de Outubro de 2009 11:12
> To: [email protected]
> Cc: Manuel Lemos; [email protected]; MEM; Bob McConnell
> Subject: Re: [PHP] Self-Process php forms or not?
>
> >> You say you don't use hidden fields because they can be modified too
> >> easily, yet you say you check for the submit button? Which out of
> the
> >> two do you do, as last time I checked, modifying one form field is
> as
> >> easy as changing any other!
> I completely agree with you. changing submit text is as easy as
> changing hidden fields, but its less likely for a user to modify a
> submit button as compared to a hidden field. moreover it just reduces
> my typing load. (This is just my practice)
>
> >> Also worth noting, you can only successfully check for the
> name="submit"
> >> value if there is only one submit button in your form, as that is
> then
> >> the default (and only) submit that the form can use, so it uses that.
> If
> >> you have more than one submit button (and this includes image input
> >> elements) then using the keyboard will use the first submit field it
> >> finds I believe.
> Cant agree with you on this though. as far as i know using name=""
> (names of the two buttons may/may not be unique) is the only way to
> track form submission for forms with multiple submit buttons. Please
> point out if you think otherwise
>
> --
> Kranthi.
--- End Message ---
--- Begin Message ---
At 1:55 PM +0530 10/2/09, kranthi wrote:
and yes i forgot to mention... i avoid hidden form elements because
they can be modified very easily and hence pose a security threat.
That depends upon how sloppy you are in coding.
NONE of my hidden variables pose any security problems whatsoever.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
At 3:06 PM +0100 10/2/09, MEM wrote:
I want to apologize to you all. I have mentioned two things on the same
basket, but it was not appropriate. Since a confirmation page is not the
same thing as a success page.
Let's forget about the confirmation page, since it's not required.
I'm now understanding that even if the form is submitted to self, we can
still use a redirect to a "success_message_page.php". However, we must do
this redirect, AFTER the form has submitted to himself. It's the only thing
that we have to pay attention here, correct?
Since we are not dealing with a confirmation page, or a multi-step form, the
hidden field isn't necessary.
It's this correct assumptions?
Please advice,
Regards,
Márcio
You can set it up any number of ways. There is no
absolute need for a redirect. Everything can be
done in one form, or not -- your choice.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
> You can set it up any number of ways. There is no
> absolute need for a redirect. Everything can be
> done in one form, or not -- your choice.
>
> Cheers,
>
> tedd
Yes. But since I don't want to display a success information + form fields,
but only the success information,
I believe the only way we have to do this is by either use javascript and
update a div or similar, or using only php, by redirecting to another page.
Is this correct?
--- End Message ---
--- Begin Message ---
At 3:35 PM +0100 10/2/09, MEM wrote:
> You can set it up any number of ways. There is no
absolute need for a redirect. Everything can be
done in one form, or not -- your choice.
Cheers,
tedd
Yes. But since I don't want to display a success information + form fields,
but only the success information,
I believe the only way we have to do this is by either use javascript and
update a div or similar, or using only php, by redirecting to another page.
Is this correct?
No -- and you are not listening.
I gave you the way to do it, but you are taking another path. As
always, it's your choice.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
> Yes. But since I don't want to display a success information + form fields,
> but only the success information,
> I believe the only way we have to do this is by either use javascript and
> update a div or similar, or using only php, by redirecting to another page.
>
> Is this correct?
Whether or not it's the only way, redirecting to a success page is
probably the best way, from a user-experience perspective. It keeps
the browser history sane and avoids possible trouble with
page-refreshes.
Google for "post redirect get" and you'll find all sorts of
discussions of this pattern. Here's one of the clearer articles that
came up on the first page of results, when I ran that search:
http://www.andypemberton.com/engineering/the-post-redirect-get-pattern/
Ben
--- End Message ---
--- Begin Message ---
Hello,
on 10/02/2009 05:23 AM kranthi said the following:
>>> That only works if the user clicks on that submit button. If the user
>>> hits the enter key in a text input, the form is submitted but the submit
>>> input variable is not set. That is why an hidden input is a safer solution.
>
> i doubt that, because i use the above mentioned method in nearly all
> of my projects, and all of them are working fine.
>
> P.S: i prefer keyboard to mouse as a input device
Sorry, what I meant is that if you have multiple submit buttons in your
form, say "Preview", "Save" and "Cancel", if you hit enter in a text
input it will not set the variables for all buttons. At most only one
button variable is set, which usually is the first button in the HTML,
but you have no way to change which will be set.
If you use an hidden field is easier to determine whether the form was
submitted or not, as you do not have to check variables for all buttons.
--
Regards,
Manuel Lemos
Find and post PHP jobs
http://www.phpclasses.org/jobs/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
Hello,
on 10/02/2009 05:25 AM kranthi said the following:
> and yes i forgot to mention... i avoid hidden form elements because
> they can be modified very easily and hence pose a security threat.
How can hidden field be changed in a way that submit buttons can't? I do
not see any security threat scenario.
--
Regards,
Manuel Lemos
Find and post PHP jobs
http://www.phpclasses.org/jobs/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
Hello,
on 10/02/2009 07:11 AM kranthi said the following:
>>> You say you don't use hidden fields because they can be modified too
>>> easily, yet you say you check for the submit button? Which out of the
>>> two do you do, as last time I checked, modifying one form field is as
>>> easy as changing any other!
> I completely agree with you. changing submit text is as easy as
> changing hidden fields, but its less likely for a user to modify a
> submit button as compared to a hidden field. moreover it just reduces
> my typing load. (This is just my practice)
How come an user can modify a hidden field is more likely to change
submit button? I don't think an average user will modify anything at all.
>>> Also worth noting, you can only successfully check for the name="submit"
>>> value if there is only one submit button in your form, as that is then
>>> the default (and only) submit that the form can use, so it uses that. If
>>> you have more than one submit button (and this includes image input
>>> elements) then using the keyboard will use the first submit field it
>>> finds I believe.
> Cant agree with you on this though. as far as i know using name=""
> (names of the two buttons may/may not be unique) is the only way to
> track form submission for forms with multiple submit buttons. Please
> point out if you think otherwise
As everbody has been telling you, if you check an hidden field it will
work regardless whether the user clicked on a button or hit enter on a
text input. With multiple buttons there is no way (except for using some
Javascript) to tell whether it was clicked a button or the user hit
enter in a text input.
--
Regards,
Manuel Lemos
Find and post PHP jobs
http://www.phpclasses.org/jobs/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
On Fri, 2009-10-02 at 18:07 +0530, kranthi wrote:
> >> I've read that the upcoming Firefox 4 may have some features built in
> >> for this sort of thing, and there are plugins out there for most
> >> browsers that can do this as an added layer of security.
> Sorry but I could not understand what you meant by "this"
>
> coming back to original problem... you should keep in mind that if
> base tag is used, the links (<a href="...">) in that page will become
> absolute links instead of relative links
>
"this" is this:
"Some browser security settings may not allow you to run Javascript code
that exists on another server though"
Also, you won't have to worry about the links, unless you wanted the
links that were relative to the remote site to be relative to your own.
This would only work out in such a way if you'd scraped their whole site
for content, which would beg the question, "why would someone honestly
need to scrape an entire site?"
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
At 4:29 PM -0400 10/1/09, Robert Cummings wrote:
I'm a superstar... send me a check for $500,000 and I'll fly on over.
Or did you completely misuse the word "superstar"?
Cheers,
Rob.
Rob:
Well, in my book you are a superstar.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
<?PHP
$num = 123;
$num = $num++;
print $num; //this prints 123 and not 124 ?!!
$num = 123;
$num = ++$num;
print $num; //this prints 124 as expected
$num = 123;
$num++;
print $num; //this prints 124 as expected
$num = 123;
print $num++; //this prints 123 and not 124 ?!!
print $num++; //this NOW prints 124
?>
So then I read the manual because I think I'm loosing my mind and perhaps
it's backwards day and nobody told me:
http://us3.php.net/manual/en/language.operators.increment.php
I'm baffled as to the reasoning behind:
"$a++ :: Post-increment :: Returns $a, then increments $a by one."
Why would you EVER want $num = $num++; to give you back the value you
already had? Even if we did $foo = $bar++; I would still logically (and
common sensely) expect $foo to be the increment of $bar!
It also seems counter-intuitive, as I was always lead to believe everything
is processed on the right of an equals sign and then assigned back to the
left side of the equals sign. In this case, it does a mixture of both.
Can someone PLEASE explain why the developers of PHP chose this seemingly
whacky logic?
--- End Message ---
--- Begin Message ---
> Can someone PLEASE explain why the developers of PHP chose this seemingly
> whacky logic?
It mimicks C.
Ben
--- End Message ---
--- Begin Message ---
Daevid Vincent wrote:
<?PHP
$num = 123;
$num = $num++;
print $num; //this prints 123 and not 124 ?!!
$num = 123;
$num = ++$num;
print $num; //this prints 124 as expected
$num = 123;
$num++;
print $num; //this prints 124 as expected
$num = 123;
print $num++; //this prints 123 and not 124 ?!!
print $num++; //this NOW prints 124
?>
So then I read the manual because I think I'm loosing my mind and perhaps
it's backwards day and nobody told me:
http://us3.php.net/manual/en/language.operators.increment.php
I'm baffled as to the reasoning behind:
"$a++ :: Post-increment :: Returns $a, then increments $a by one."
Why would you EVER want $num = $num++; to give you back the value you
already had? Even if we did $foo = $bar++; I would still logically (and
common sensely) expect $foo to be the increment of $bar!
It also seems counter-intuitive, as I was always lead to believe everything
is processed on the right of an equals sign and then assigned back to the
left side of the equals sign. In this case, it does a mixture of both.
Can someone PLEASE explain why the developers of PHP chose this seemingly
whacky logic?
This logic is almost universal in modern programming languages. Some
people do the following:
<?php
$index = 1;
foreach( @items as @item )
{
echo '<tr>'
.'<td>'.($index++).'</td>'
.'<td>'.$item.'</td>'
.'</tr>';
}
?>
Some people consider it weird to start at 0 for the above index, because
the index is only used when it is 1 or more. But the equivalent of the
above is the following:
<?php
$index = 0;
foreach( @items as @item )
{
echo '<tr>'
.'<td>'.(++$index).'</td>'
.'<td>'.$item.'</td>'
.'</tr>';
}
?>
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
----- Original Message ----
> From: Ben Dunlap <[email protected]>
> To: Daevid Vincent <[email protected]>
> Cc: [email protected]
> Sent: Fri, October 2, 2009 2:06:47 PM
> Subject: Re: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
>
> > Can someone PLEASE explain why the developers of PHP chose this seemingly
> > whacky logic?
>
> It mimicks C.
>
> Ben
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
Any language based on C has it, such as C++, Java and C#. It gives
programmers/developers flexibility when to increment and use its value.
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Robert Cummings [mailto:[email protected]]
> Sent: Friday, October 02, 2009 2:12 PM
> To: Daevid Vincent
> Cc: [email protected]
> Subject: Re: [PHP] Whacky increment/assignment logic with
> $foo++ vs ++$foo
>
> Daevid Vincent wrote:
> > <?PHP
> > $num = 123;
> > $num = $num++;
> > print $num; //this prints 123 and not 124 ?!!
> >
> > $num = 123;
> > $num = ++$num;
> > print $num; //this prints 124 as expected
> >
> > $num = 123;
> > $num++;
> > print $num; //this prints 124 as expected
> >
> > $num = 123;
> > print $num++; //this prints 123 and not 124 ?!!
> > print $num++; //this NOW prints 124
> > ?>
> >
> > So then I read the manual because I think I'm loosing my
> mind and perhaps
> > it's backwards day and nobody told me:
> > http://us3.php.net/manual/en/language.operators.increment.php
> >
> > I'm baffled as to the reasoning behind:
> > "$a++ :: Post-increment :: Returns $a, then increments $a by one."
> >
> > Why would you EVER want $num = $num++; to give you back the
> value you
> > already had? Even if we did $foo = $bar++; I would still
> logically (and
> > common sensely) expect $foo to be the increment of $bar!
> >
> > It also seems counter-intuitive, as I was always lead to
> believe everything
> > is processed on the right of an equals sign and then
> assigned back to the
> > left side of the equals sign. In this case, it does a
> mixture of both.
> >
> > Can someone PLEASE explain why the developers of PHP chose
> this seemingly
> > whacky logic?
>
> This logic is almost universal in modern programming languages. Some
> people do the following:
>
> <?php
>
> $index = 1;
> foreach( @items as @item )
> {
> echo '<tr>'
> .'<td>'.($index++).'</td>'
> .'<td>'.$item.'</td>'
> .'</tr>';
> }
>
> ?>
>
> Some people consider it weird to start at 0 for the above
> index, because
> the index is only used when it is 1 or more. But the
> equivalent of the
> above is the following:
>
> <?php
>
> $index = 0;
> foreach( @items as @item )
> {
> echo '<tr>'
> .'<td>'.(++$index).'</td>'
> .'<td>'.$item.'</td>'
> .'</tr>';
> }
>
> ?>
My problem isn't with $foo++ vs ++$foo per say. I use pre/post all the time.
My issue is that I see no reason to do the ASSIGNMENT FIRST and THEN
INCREMENT.
That's just counter intuitive. In the case of $foo = $num++, everything to
the right of the = should be computed FIRST and THEN handed off to the left
side. This particular expression (and I'm unaware of any other PHP
expression that works this way) chooses to do some "FM" (f'n magic) and do
an assignment FIRST and THEN increment.
All of this is just an academic discussion at this point, as I'm sure there
is WAY too much code out there to even consider changing this behaviour to a
more sane one. And I'm told it mimics other languages (wright or wrong, it
is what it is).
Personally I've never (in almost 20 years) done an assignment like "$foo =
$foo++" as I always use just "$foo++" or "$foo += 1" or something, hence the
reason today is the day a co-worker stumbled upon this and was as confused
as I was until I figured it out.
D.
--- End Message ---
--- Begin Message ---
> My issue is that I see no reason to do the ASSIGNMENT FIRST and THEN
> INCREMENT.
>
> That's just counter intuitive. In the case of $foo = $num++, everything to
> the right of the = should be computed FIRST and THEN handed off to the left
> side. This particular expression (and I'm unaware of any other PHP
> expression that works this way) chooses to do some "FM" (f'n magic) and do
> an assignment FIRST and THEN increment.
It's not the expression that works that way -- it's the operator. The
post-increment operator /always/ does its work after the expression
that it's in has been evaluated.
Are you thinking it would be more intuitive if that operator departed
from its normal behavior in this one special case?
Ben
--- End Message ---
--- Begin Message ---
On Fri, Oct 2, 2009 at 17:28, Daevid Vincent <[email protected]> wrote:
>
> Personally I've never (in almost 20 years) done an assignment like "$foo =
> $foo++" as I always use just "$foo++" or "$foo += 1" or something, hence the
> reason today is the day a co-worker stumbled upon this and was as confused
> as I was until I figured it out.
And that's exactly the point: why would you assign this variable
to another in the first place? It's just using up resources and
creating more overhead in the application. The reason it exists is
for processing, really, not assigning; and the ability to do it before
or after is appropriate for certain conditions. However, keep in mind
that you don't even need to do anything with the variable to increment
it:
<?php
$n = 1;
$n++;
echo $n."\n"; // 2
?>
The $var++ vs. ++$var (or, conversely, $var-- vs. --$var)
comparison isn't best described by the most commonly-used incrementing
scenario:
<?php
$a = array('foo' => 'bar', 'apple' => 'red', 'lime' => 'green', 'wife'
=> 'pain in ass', 'lemon' => 'yellow');
for($i=0;$i<count($a);$i++) {
// ....
}
?>
.... but rather by something just slightly more advanced:
<?php
$num = file_get_contents('visitcount.txt');
if(isset($_GET['countme'])) {
echo "You are visitor #".++$num."<br />\n";
file_put_contents($num);
}
?>
If you were to use $num++, it would echo out the current number,
THEN increment the value. In this example, it increments the value,
THEN echoes it out. The placement of the signs (plus or minus) is the
giveaway: if it's before the variable, it's modified before being
processed. If it's after, then it's evaluated immediately after the
variable is processed.
--
</Daniel P. Brown>
[email protected] || [email protected]
http://www.parasane.net/ || http://www.pilotpig.net/
Check out our great hosting and dedicated server deals at
http://twitter.com/pilotpig
--- End Message ---
--- Begin Message ---
On Fri, Oct 2, 2009 at 17:42, Daniel Brown <[email protected]> wrote:
>
> .... but rather by something just slightly more advanced:
>
> <?php
> $num = file_get_contents('visitcount.txt');
> if(isset($_GET['countme'])) {
> echo "You are visitor #".++$num."<br />\n";
> file_put_contents($num);
> }
> ?>
Converse example (sorry, forgot to add it):
<?php
$num = file_get_contents('visitcount.txt');
if(isset($_GET['countme'])) {
echo "There were ".$num++." people here before you.<br />\n";
file_put_contents($num);
}
?>
--
</Daniel P. Brown>
[email protected] || [email protected]
http://www.parasane.net/ || http://www.pilotpig.net/
Check out our great hosting and dedicated server deals at
http://twitter.com/pilotpig
--- End Message ---
--- Begin Message ---
On Fri, Oct 2, 2009 at 2:37 PM, Ben Dunlap <[email protected]> wrote:
>> My issue is that I see no reason to do the ASSIGNMENT FIRST and THEN
>> INCREMENT.
>>
>> That's just counter intuitive. In the case of $foo = $num++, everything to
>> the right of the = should be computed FIRST and THEN handed off to the left
>> side. This particular expression (and I'm unaware of any other PHP
>> expression that works this way) chooses to do some "FM" (f'n magic) and do
>> an assignment FIRST and THEN increment.
>
> It's not the expression that works that way -- it's the operator. The
> post-increment operator /always/ does its work after the expression
> that it's in has been evaluated.
>
> Are you thinking it would be more intuitive if that operator departed
> from its normal behavior in this one special case?
On further thought I do see why this one special case is a little
mind-blowing. What the heck /is/ supposed to happen when you do this:
$a = 2;
$a = $a++;
echo $a;
Seems like any way you slice it the output should be 3. I guess what's
revealed here is that, as far as PHP is concerned, the $a on the right
side of the assignment expression is something like a temporary copy
of the variable in the current scope. So the assignment gets
evaluated, and then ++ operates on that "copy" and the result is
discarded.
Honestly I think the only reason anyone would write an expression like
that is either to fake out the compiler or because they don't properly
understand the use of a unary operator. Or rather, of the
increment/decrement operators, because no other unary operator
actually changes the thing it operates on (AFAIK), which makes ++ and
-- doubly weird.
Ben
--- End Message ---
--- Begin Message ---
> mind-blowing. What the heck /is/ supposed to happen when you do this:
>
> $a = 2;
> $a = $a++;
> echo $a;
>
> Seems like any way you slice it the output should be 3. I guess what's
... and, in fact, that /is/ how C behaves. The following code:
int a = 2;
a = a++;
printf("a = [%d]\n", a);
Will output "a = [3]". At least on Ubuntu 9 using gcc 4.3.3.
So I retract my initial terse reply and apologize for misunderstanding
your question.
Ben
--- End Message ---
--- Begin Message ---
>> Seems like any way you slice it the output should be 3. I guess what's
>
> ... and, in fact, that /is/ how C behaves. The following code:
Whereas Perl (v5.10.0) handles the construct the same way that PHP
does. Curiouser and curiouser.
Ben
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Ben Dunlap [mailto:[email protected]]
> Sent: Friday, October 02, 2009 2:58 PM
> To: [email protected]; Daevid Vincent
> Subject: Re: [PHP] Whacky increment/assignment logic with
> $foo++ vs ++$foo
>
> > mind-blowing. What the heck /is/ supposed to happen when
> you do this:
> >
> > $a = 2;
> > $a = $a++;
> > echo $a;
> >
> > Seems like any way you slice it the output should be 3. I
> guess what's
>
> ... and, in fact, that /is/ how C behaves. The following code:
>
> int a = 2;
> a = a++;
> printf("a = [%d]\n", a);
>
> Will output "a = [3]". At least on Ubuntu 9 using gcc 4.3.3.
>
> So I retract my initial terse reply and apologize for misunderstanding
> your question.
>
> Ben
EXACTLY! :)
God (or diety of your choice) bless you for "getting" what I'm saying and
proving that it's not "C" like either. That just adds credence to my/our
argument.
d
--- End Message ---
--- Begin Message ---
On Oct 2, 2009, at 15:22, Daevid Vincent wrote:
-----Original Message-----
From: Ben Dunlap [mailto:[email protected]]
Sent: Friday, October 02, 2009 2:58 PM
To: [email protected]; Daevid Vincent
Subject: Re: [PHP] Whacky increment/assignment logic with
$foo++ vs ++$foo
mind-blowing. What the heck /is/ supposed to happen when
you do this:
$a = 2;
$a = $a++;
echo $a;
Seems like any way you slice it the output should be 3. I
guess what's
... and, in fact, that /is/ how C behaves. The following code:
int a = 2;
a = a++;
printf("a = [%d]\n", a);
Will output "a = [3]". At least on Ubuntu 9 using gcc 4.3.3.
So I retract my initial terse reply and apologize for
misunderstanding
your question.
Ben
EXACTLY! :)
God (or diety of your choice) bless you for "getting" what I'm
saying and
proving that it's not "C" like either. That just adds credence to
my/our
argument.
d
I think if you rewrote the above example as
int a = 2;
b = a++;
printf("b = [%d]\n", b);
"b" would be 2 when printed. However, after the second line (b = a+
+;) finished executing, "a" would then be 3.
--- End Message ---
--- Begin Message ---
> int a = 2;
> b = a++;
> printf("b = [%d]\n", b);
>
> "b" would be 2 when printed. However, after the second line (b = a++;)
> finished executing, "a" would then be 3.
Sure, but that code is perfectly clear. It's the odd special case
where you assign the variable to itself, that's ambiguous. Like Daevid
said, academic at this point -- but it might shed light on some
compiler-design decisions that I don't have the vocabulary for.
OTOH it could just a be a unique case with unpredictable results.
Ben
--- End Message ---
--- Begin Message ---
"Daevid Vincent" wrote:
>
>
>> -----Original Message-----
>> From: Ben Dunlap [mailto:[email protected]]
>> Sent: Friday, October 02, 2009 2:58 PM
>> To: [email protected]; Daevid Vincent
>> Subject: Re: [PHP] Whacky increment/assignment logic with
>> $foo++ vs ++$foo
>>
>> > mind-blowing. What the heck /is/ supposed to happen when
>> you do this:
>> >
>> > $a = 2;
>> > $a = $a++;
>> > echo $a;
>> >
>> > Seems like any way you slice it the output should be 3. I
>> guess what's
>>
>> ... and, in fact, that /is/ how C behaves. The following code:
>>
>> int a = 2;
>> a = a++;
>> printf("a = [%d]\n", a);
>>
>> Will output "a = [3]". At least on Ubuntu 9 using gcc 4.3.3.
>>
>> So I retract my initial terse reply and apologize for misunderstanding
>> your question.
>>
>> Ben
>
> EXACTLY! :)
>
> God (or diety of your choice) bless you for "getting" what I'm saying and
> proving that it's not "C" like either. That just adds credence to my/our
> argument.
>
>
> d
Well, Daevid,
I still do appreciate the difference between
$a = 1;
$b = $a++;
// $b should be 1
and
$a = $a++;
$b = $a;
// $b should be 2
unless PHP manages to exhibit some overlay problem (read: bug) for $a in
the 2nd case.
True?
joost.
--- End Message ---
--- Begin Message ---
I was hoping someone might be able to help me with something. In a recent
effort to learn PHP/mySQL, I decided to design a mock forum. Many forums
(such as phpBB) allow a user to pick their timezone and to select if DST
should be applied. I'm trying to figure out how its done. Currently, I'm
saving all times as GMT, having set the default timezone to 'Europe/London'.
I then found this list of timezones:
http://unicode.org/repos/cldr/trunk/docs/design/formatting/zone_log.html#windows_ids
The issue I'm having trouble with now is DST. I just learned that not all
timezones start DST on the same day, nor do they all add one hour.
According to http://www.php.net/manual/en/datetime.getoffset.php
DateTime::getOffset should give me back the DST offset, but when I have use
DateTime::setTimezone to change the timezone and get the local users time,
it automatically applies DST if applicable, and setTimezone gives me
back -14400 (I'm testing with EST). This is -4 hours, which is the offset
from GMT to EST right now. Unless I'm using the funciton wrong, it seems to
give the offset from GMT. Can anyone lend me a thought?
--- End Message ---
