php-general Digest 4 Oct 2009 02:30:24 -0000 Issue 6372

Sat, 03 Oct 2009 19:33:21 -0700 

php-general Digest 4 Oct 2009 02:30:24 -0000 Issue 6372

Topics (messages 298518 through 298543):

Re: Self-Process php forms or not?
        298518 by: tedd
        298519 by: tedd
        298528 by: Tom Worster

Re: Header problem
        298520 by: kranthi

Re: A really wacky design decision
        298521 by: tedd
        298530 by: Tom Worster
        298531 by: Tom Worster
        298532 by: Ashley Sheridan
        298533 by: Robert Cummings
        298534 by: Tom Worster
        298535 by: Robert Cummings
        298538 by: Andrea Giammarchi
        298539 by: Robert Cummings
        298540 by: Andrea Giammarchi
        298541 by: tedd

Re: Whacky increment/assignment logic with $foo++ vs ++$foo
        298522 by: tedd
        298523 by: tedd
        298524 by: tedd
        298525 by: tedd
        298526 by: tedd
        298529 by: Daniel Brown
        298536 by: Andrea Giammarchi
        298542 by: Lupus Michaelis

Re: Problem with Filesystem Functions
        298527 by: Andrew Burgess

problem with mod_php
        298537 by: JC

Missing php5apache2.dll
        298543 by: Floydian

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 --- 
At 7:11 PM +0100 10/2/09, MEM wrote:

I don't want to take another path. The hidden fields seems the way to go.
However, you gave me the example above, and I'm not understanding how can I
pass from your example: A multi-step form.
To what I was looking form: 1 step form with a success page that shows no
form elements.

Sorry if I've not understand. I was having no intention of doing so.

Regards,
Márcio



Márcio:

At some point here, you must take keyboard in hand and program this yourself.

If you took my code and ran it, then you would understand.

Here's a working example:

http://www.webbytedd.com/aa/step-form/

This only one of many ways to solve your problem, but it does solve it.

Cheers,

tedd
PS: Please reply to the list and not me privately, unless you are hiring me (learned that from Stut) 
--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message --- 
At 9:42 AM -0400 10/3/09, Tom Worster wrote:

On 10/2/09 10:24 AM, "tedd" <[email protected]> wrote:


 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.


...because one always assumes that data supplied in an http request is
tainted. hence arguments about which exploit is more likely is rather
pointless.

a hidden input is really no different from any other form field. kranthi's
argument would be consistent if he felt that all form inputs should be
avoided because they are so easily modified as to pose a security threat.


Exactly.

All data gathered via forms, hidden or not, must be sanitized.

Cheers,

tedd
--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message --- 
On 10/2/09 10:06 AM, "MEM" <[email protected]> wrote:

> 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?

the server script that runs in response to an http request for uri X can
determine if "conditions of success" are met only after the server receives
the request for X. so, if i understand your question, yes.

i think your terminology is confusing you, e.g.: "AFTER the form has
submitted to himself". a form doesn't submit to itself. a form and a script
that processes it are SEPARATE THINGS.

it's better to think in terms of a user agent and a server communicating
with http requests and responses. the UA sends http requests for uris X, Y,
Z, etc. (with or without accompanying form data). the forms are part of html
pages the server sends to the UA in http responses. a user drives the UA.
PHP scripts are involved in the server's generation of responses. (a diagram
might help.)

now to your queston:

if a UA has an html page that it got in a response for uri X; and if the
page has a form; and if the form has no action attribute (or action=X); and
if the user submits the form; then the UA will send the server an http
request for X.

next the server receives the request for X and the server runs a certain
script, the php script you are coding.

now i'm assuming these are your requirements: if that script determines
failure, the user says at X and is asked to resubmit the form. if the script
determines success, the user will wind up at a new uri: Y. further, you want
to send the user over to Y by sending her UA an http response with
Location=Y redirection.

in these terms, the answer to your question should be pretty clear. your
script has to receive and process requests for X before it can decide if
it's going to respond to the UA with a Location=Y redirection or an html
page with a form and an error message.

--- End Message ---
--- Begin Message --- 
Thats a lot of headers to read..
At a first glance I can see that you did not specify a content-length
header. this is a must and must be equal to the size of the file in
bytes

-- 
Kranthi.

--- End Message ---
--- Begin Message --- 
At 9:21 PM +1000 10/3/09, [email protected] wrote:

Daevid Vincent is surprised that:

$num = 123;
$num = $num++;
print $num;  //this prints 123 and not 124 ?!!
I can understand why someone might think this is not correct, but they need to understand what is happening and why the above second assignment statement is in bad form (IMO). 

The first statement assigns 123 to $num. Everyone is OK with that.
The next statement assigns 123 to $num, but then tries to increment $num, but doesn't because the assignment overrides the ++ operator -- this is bad form (IMO). 

Now, if you change the syntax to this:

$num = 123;
$num = ++num;
print $num;            //this prints 124

The first statement assigns 123 to $num.
The next statement adds 1 to $num and then assigns 124 to $num, but it's still not the best form because you can do the same thing with: 

++$num;

OR

$num++;
It's usually easier to understand if one doesn't compound statements with ++ operator. 

Cheers,

tedd

--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message --- 
On 10/3/09 9:53 AM, "Ralph Deffke" <[email protected]> wrote:

> this is a clear sign that somebody is on a sin TRAIL, I would not even spend
> the time on  what sin collections this guy got

i see it more as ignorance than sin.

to misunderstand the difference between $n++ and ++$n is a beginner error.

as k&r made very clear with their sequences of lessons in the original book,
without actually saying so, becoming "an experienced programming" is like
becoming a zen master. it is a progression to sophistication, the exemplars
of which can be found here:

http://www1.us.ioccc.org/years-spoiler.html

i particularly recommend herrmann2 from 2001. masterful and dumbfounding.
read the .hint file.

--- End Message ---
--- Begin Message --- 
On 10/3/09 7:21 AM, "[email protected]" <[email protected]> wrote:

> However there is one feature of PHP which, to my mind, is really bad design.
> How many of
> you can see anything wrong with the following procedure to search a list of
> names for a
> particular name?
> 
> $i = 0; $j = count ($names); while ($i < $j)
> { if ($names[$i] == $target) { break; }
> ++$i;
> }
> 
> As long as the names are conventional names, this procedure is probably safe
> to use.
> However if you allow the names to be general alphanumeric strings, it is not
> reliable. One
> of my programs recently broke down in one particular case, and when I
> eventually isolated
> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
> this is: 226E1
> = 226*10^1 = 2260).
> 
> I agree that I was well aware of this trap, and that I should not have used a
> simple
> comparison, but it seems to me to be a bizarre design decision to assume that
> anything
> which can be converted to an integer, using any of the available notations, is
> in fact an
> integer, rather than making the default to simply treat it as a string.

this is odd.

i might think it ok for (2260 == '226E1') to be true since php would be
doing type juggling in a logical left-to-right manner: we start with an
integer 2260, next is the juggling comparison operator, then a string, so it
might reasonably try to convert the string to an integer and then compare.

but with ('2260' == '226E1'), where both lhs and rhs are already of the same
time, it seems elliptical, to say the least, that php should search the
types to which it can convert the strings looking for one in which they are
equal.

--- End Message ---
--- Begin Message --- 
On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:

> On 10/3/09 7:21 AM, "[email protected]" <[email protected]> wrote:
> 
> > However there is one feature of PHP which, to my mind, is really bad design.
> > How many of
> > you can see anything wrong with the following procedure to search a list of
> > names for a
> > particular name?
> > 
> > $i = 0; $j = count ($names); while ($i < $j)
> > { if ($names[$i] == $target) { break; }
> > ++$i;
> > }
> > 
> > As long as the names are conventional names, this procedure is probably safe
> > to use.
> > However if you allow the names to be general alphanumeric strings, it is not
> > reliable. One
> > of my programs recently broke down in one particular case, and when I
> > eventually isolated
> > the bug I discovered that it was matching '2260' to '226E1'. (The logic of
> > this is: 226E1
> > = 226*10^1 = 2260).
> > 
> > I agree that I was well aware of this trap, and that I should not have used 
> > a
> > simple
> > comparison, but it seems to me to be a bizarre design decision to assume 
> > that
> > anything
> > which can be converted to an integer, using any of the available notations, 
> > is
> > in fact an
> > integer, rather than making the default to simply treat it as a string.
> 
> this is odd.
> 
> i might think it ok for (2260 == '226E1') to be true since php would be
> doing type juggling in a logical left-to-right manner: we start with an
> integer 2260, next is the juggling comparison operator, then a string, so it
> might reasonably try to convert the string to an integer and then compare.
> 
> but with ('2260' == '226E1'), where both lhs and rhs are already of the same
> time, it seems elliptical, to say the least, that php should search the
> types to which it can convert the strings looking for one in which they are
> equal.
> 
> 
> 


I don't know what you mean by elliptical, but I'd expect and certainly
hope that PHP wouldn't try to convert both strings to something which
would mean they had the same value. Also, afaik, if the variables types
are exactly the same, PHP won't try to convert either of them for a
comparison

Thanks,
Ash
http://www.ashleysheridan.co.uk

--- End Message ---
--- Begin Message --- 


tedd wrote:

At 9:21 PM +1000 10/3/09, [email protected] wrote:

Daevid Vincent is surprised that:

$num = 123;
$num = $num++;
print $num;  //this prints 123 and not 124 ?!!
I can understand why someone might think this is not correct, but they need to understand what is happening and why the above second assignment statement is in bad form (IMO). 

The first statement assigns 123 to $num. Everyone is OK with that.
The next statement assigns 123 to $num, but then tries to increment $num, but doesn't because the assignment overrides the ++ operator -- this is bad form (IMO).
While I absolutely agree that it is bad form, I think you got the actual flow wrong. I think the $num++ copies the current value of $num, then increments $num to 124, then the previously copied value is returned at which point the assignment operator receives it and then overwrites the 124 with the copy of 123. 

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--- End Message ---
--- Begin Message --- 
On 10/3/09 12:25 PM, "Ashley Sheridan" <[email protected]> wrote:

> On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:
> 
>> On 10/3/09 7:21 AM, "[email protected]" <[email protected]> wrote:
>> 
>>> However there is one feature of PHP which, to my mind, is really bad design.
>>> How many of
>>> you can see anything wrong with the following procedure to search a list of
>>> names for a
>>> particular name?
>>> 
>>> $i = 0; $j = count ($names); while ($i < $j)
>>> { if ($names[$i] == $target) { break; }
>>> ++$i;
>>> }
>>> 
>>> As long as the names are conventional names, this procedure is probably safe
>>> to use.
>>> However if you allow the names to be general alphanumeric strings, it is not
>>> reliable. One
>>> of my programs recently broke down in one particular case, and when I
>>> eventually isolated
>>> the bug I discovered that it was matching '2260' to '226E1'. (The logic of
>>> this is: 226E1
>>> = 226*10^1 = 2260).
>>> 
>>> I agree that I was well aware of this trap, and that I should not have used
>>> a
>>> simple
>>> comparison, but it seems to me to be a bizarre design decision to assume
>>> that
>>> anything
>>> which can be converted to an integer, using any of the available notations,
>>> is
>>> in fact an
>>> integer, rather than making the default to simply treat it as a string.
>> 
>> this is odd.
>> 
>> i might think it ok for (2260 == '226E1') to be true since php would be
>> doing type juggling in a logical left-to-right manner: we start with an
>> integer 2260, next is the juggling comparison operator, then a string, so it
>> might reasonably try to convert the string to an integer and then compare.
>> 
>> but with ('2260' == '226E1'), where both lhs and rhs are already of the same
>> time, it seems elliptical, to say the least, that php should search the
>> types to which it can convert the strings looking for one in which they are
>> equal.
>> 
> 
> I don't know what you mean by elliptical, but I'd expect and certainly
> hope that PHP wouldn't try to convert both strings to something which
> would mean they had the same value. Also, afaik, if the variables types
> are exactly the same, PHP won't try to convert either of them for a
> comparison

i once had such hope too.

$ php -r "var_dump('2260' == '226E1');"
bool(true)


elliptical: tending to be ambiguous, cryptic, or obscure: an elliptical
prose that is difficult to translate.
(http://dictionary.reference.com/browse/elliptical)

--- End Message ---
--- Begin Message --- 
Tom Worster wrote:

On 10/3/09 12:25 PM, "Ashley Sheridan" <[email protected]> wrote:


On Sat, 2009-10-03 at 11:57 -0400, Tom Worster wrote:


On 10/3/09 7:21 AM, "[email protected]" <[email protected]> wrote:


However there is one feature of PHP which, to my mind, is really bad design.
How many of
you can see anything wrong with the following procedure to search a list of
names for a
particular name?

$i = 0; $j = count ($names); while ($i < $j)
{ if ($names[$i] == $target) { break; }
++$i;
}

As long as the names are conventional names, this procedure is probably safe
to use.
However if you allow the names to be general alphanumeric strings, it is not
reliable. One
of my programs recently broke down in one particular case, and when I
eventually isolated
the bug I discovered that it was matching '2260' to '226E1'. (The logic of
this is: 226E1
= 226*10^1 = 2260).

I agree that I was well aware of this trap, and that I should not have used
a
simple
comparison, but it seems to me to be a bizarre design decision to assume
that
anything
which can be converted to an integer, using any of the available notations,
is
in fact an
integer, rather than making the default to simply treat it as a string.

this is odd.

i might think it ok for (2260 == '226E1') to be true since php would be
doing type juggling in a logical left-to-right manner: we start with an
integer 2260, next is the juggling comparison operator, then a string, so it
might reasonably try to convert the string to an integer and then compare.

but with ('2260' == '226E1'), where both lhs and rhs are already of the same
time, it seems elliptical, to say the least, that php should search the
types to which it can convert the strings looking for one in which they are
equal.


I don't know what you mean by elliptical, but I'd expect and certainly
hope that PHP wouldn't try to convert both strings to something which
would mean they had the same value. Also, afaik, if the variables types
are exactly the same, PHP won't try to convert either of them for a
comparison


i once had such hope too.

$ php -r "var_dump('2260' == '226E1');"
bool(true)


Numeric strings are special :)

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--- End Message ---
--- Begin Message --- 
if we compare via "==" there is an implicit cast to the most primitive form.

These are all true, and all have a reason, and make sense:

// (int)'abc' is 0
var_dump('abc' == 0);

// 'abc' is not an empty string
var_dump('abc' == true);

// 2 is not 0, which would be casted into false, so it's true
var_dump(2 == true);

A common error is usually in MySQL queries without explicit cast comparing 
strings to numbers as well ... this is bad, specially because every programmer 
should have at least low level programming languages basis ... that can only 
help to better understand today high level programming languages.

The reason we use, love, hate PHP as loose type scripting language does not 
mean we should avoid to understand how php works internally (C)

Loose type is only manifested to the developer, but it will never be behind 
(still C)

If you use APD or you think about the low level logic behind comparing string, 
num and bool you'll probably forget the "==" operator and you'll never miss 
again the "===" one ... then you'll start to explicit cast everything, when 
necessary, to have all your code truly under control, and that is the moment 
you'll realize PHP is not for you 'cause you are forcing a typeless language to 
be strict ... and then you'll start to develop via C, Python, Java, or C#, 
ending up with JavaScript on server side 'cause is the only scripting language, 
without pretending classic OOP, that makes sense ... (sorry for the last part 
of this reply, that's just what happened to me)

Regards
                                          
_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail 
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010

--- End Message ---
--- Begin Message --- 
Andrea Giammarchi wrote:

If you use APD or you think about the low level logic behind comparing string,
> num and bool you'll probably forget the "==" operator and you'll never miss > again the "===" one ... then you'll start to explicit cast everything, when > necessary, to have all your code truly under control, and that is the moment > you'll realize PHP is not for you 'cause you are forcing a typeless language > to be strict ... and then you'll start to develop via C, Python, Java, or C#,
PHP allows you to do either. If I find myself being more strict in no way does that mean I'll suddenly jump to another language. It just means I have a bit of code that requires a bit more strictness. Should I suddenly switch languages because when using the strpos() function I must use the === operator to check for existence of a substring? Utter silliness IMHO. 

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--- End Message ---
--- Begin Message --- 
You introduced the word "suddenly", it's about 10 years I develop in PHP

Regards


> PHP allows you to do either. If I find myself being more strict in no 
> way does that mean I'll suddenly jump to another language. It just means 
> I have a bit of code that requires a bit more strictness. Should I 
> suddenly switch languages because when using the strpos() function I 
> must use the === operator to check for existence of a substring? Utter 
> silliness IMHO.
> 
> Cheers,
> Rob.
> -- 
> http://www.interjinn.com
> Application and Templating Framework for PHP
                                          
_________________________________________________________________
Keep your friends updated—even when you’re not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010

--- End Message ---
--- Begin Message --- 
At 1:37 PM -0400 10/3/09, Robert Cummings wrote:

tedd wrote:

At 9:21 PM +1000 10/3/09, [email protected] wrote:

Daevid Vincent is surprised that:

$num = 123;
$num = $num++;
print $num;  //this prints 123 and not 124 ?!!
I can understand why someone might think this is not correct, but they need to understand what is happening and why the above second assignment statement is in bad form (IMO). 

The first statement assigns 123 to $num. Everyone is OK with that.
The next statement assigns 123 to $num, but then tries to increment $num, but doesn't because the assignment overrides the ++ operator -- this is bad form (IMO).
While I absolutely agree that it is bad form, I think you got the actual flow wrong. I think the $num++ copies the current value of $num, then increments $num to 124, then the previously copied value is returned at which point the assignment operator receives it and then overwrites the 124 with the copy of 123. 

Cheers,
Rob.
--


Rob:
That could very well be -- I really don't know the flow. That was my best guess and what made sense to me. 

Cheers,

tedd
--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message --- 
At 2:01 PM -0700 10/2/09, Daevid Vincent wrote:

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!


You are right -- one should never structure a statement like that.

Cheers,

tedd
--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message --- 
At 5:12 PM -0400 10/2/09, Robert Cummings wrote:

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.
--


Rob:

Your examples are fine -- no problems whatsoever. I do the same thing myself.

The problem I see here is with the original statement of:

$num = $$num++;

That's just bad form -- it doesn't do anything except inject confusion.

Cheers,

tedd


--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message --- 
At 2:28 PM -0700 10/2/09, Daevid Vincent wrote:

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.


I see your point exactly.

The problem is with the statement of:

$num = $num++;

That statement is just bad form. The increment is never realized.

Cheers,

tedd

--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message --- 
At 5:42 PM -0400 10/2/09, Daniel Brown wrote:

 >

    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.


That's absolutely true.

The problem here is in the statement of:

$num = $num++;

Cheers,

tedd

--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message --- 
At 2:53 PM -0700 10/2/09, Ben Dunlap wrote:

    $a = 2;
    $a = $a++;
    echo $a;
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
Honestly, I think that the only reason why one would write that is that they don't know any better. 

Why do this:

    $a = $a++;

when

    $a++;

will do what is intended?

Cheers,

tedd

--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message --- 
On Sat, Oct 3, 2009 at 10:49, tedd <[email protected]> wrote:
>
> That's absolutely true.
>
> The problem here is in the statement of:
>
> $num = $num++;

    Yeah, I understood Daevid's email a bit better *after* I sent
mine.  Then I was hoping no one noticed.

-- 
</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 --- 
> ... 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

It's not that difficult to understand ... we are talking about a scripting 
language as PHP is

The code you wrote for C is not the equivalent while this is:

int a = 2, b;
b = a++;
 printf("b = [%d]\n", b);

and b will be exactly 2.

In PHP you are not referencing that variable, you are overwriting variable $a 
with an integer, 2, and that's it.
The incremented integer, 3, is simply lost in the silly logic of the operation. 
The equivalent of your C code, in PHP, would be just this:

$a = 2;
$a++;
print $a; // of course is 3, the initial $a is not lost

or, to be more explicit ...

$a = 2;
($a = &$a) and $a++;

print $a;

Regards






                                          
_________________________________________________________________
Keep your friends updated—even when you’re not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010

--- End Message ---
--- Begin Message --- 
Ben Dunlap wrote:

... and, in fact, that /is/ how C behaves. The following code:
No, that's implementation's behaviour. AFAIK, the normative document give to compiler the behaviour implementation. So, it can do optimization, that gives strange behaviour for a people how think increment operators had a wall defined behaviour. 


        int a = 2;
        a = a++;
        printf("a = [%d]\n", a);

Will output "a = [3]". At least on Ubuntu 9 using gcc 4.3.3.


  That's gcc way :)

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

--- End Message ---
--- Begin Message --- 
On Sat, Oct 3, 2009 at 9:29 AM, Ashley Sheridan
<[email protected]> wrote:
>
> On Sat, 2009-10-03 at 09:07 -0400, Andrew Burgess wrote:
>
> I hope this isn't too basic of a question . . .
>
> I'm having a problem with the Filesystem Functions, I think.
> Specifically, I'm recursing through a directory, and have this code:
>
> $size = filesize($file);
> $type = filetype($file);
> $date = filemtime($file);
>
> I'm getting these warnings:
>
> Warning: filesize() [function.filesize]: stat failed for
> AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 33
> Warning: filetype() [function.filetype]: Lstat failed for
> AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 34
> Warning: filemtime() [function.filemtime]: stat failed for
> AudioJungle.jpg in C:\wamp\www\file_explorer\index.php on line 35
>
> These warning display for every file in the directory; however . and
> .. have no trouble. I've googled around and searched for probably
> 45min without coming up with a solution. Any help would be
> appreciated!
>
> TIA!
>
>
> Two things spring to mind. Firstly, what size are your files? I had problems 
> reading info on files over 3GB on a 32-bit PHP install, as there's a problem 
> with the number storage that leaves all the values read as 0.
>
> Second thing, are the values you're passing to these functions what you think 
> they are? While the directory browsing functions might be functioning from a 
> relative pointer, the calls to filesize() etc might need values relative to 
> the PHP script itself, or failing that, absolute path values.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>

Thanks, Ashley! Turns out, the relative paths were wrong; changing
$file to $dir . '/' . $file worked fine.

Andrew

--- End Message ---
--- Begin Message --- 
I'm trying to install a webmail in a new server with the following items:
Debian 2.6.26-2-amd64
horde 3.2.2
imp 4.2.4
apache 2.2.9
php 5.2.6
when I try to install for the first time to configure it by web, it show the
following:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to
complete your request.
Please contact the server administrator, [no address given] and inform them of
the time the error occurred, and anything you might have done that may have
caused the error.
More information about this error may be available in the server error log.

And the log (apache2 error.log) shows the following:
[Wed Sep 30 12:31:26 2009] [error] [client 200.60.166.10] (13)Permission denied:
exec of '/var/www/horde3/login.php' failed
[Wed Sep 30 12:31:26 2009] [error] [client 200.60.166.10] Premature end of
script headers: login.php

These are the permissions
-r--r--r-- 1 www-data www-data  8740 ene 29  2009 login.php

smtp:/var/www# ls -l
lrwxrwxrwx 1 root root 18 sep 27 22:31 horde3 -> /usr/share/horde3/

smtp:/usr/share# ls -l
drwxr-xr-x  18 www-data www-data  4096 sep 27 17:09 horde3


I hope you can help to resolve this problem

--- End Message ---
--- Begin Message --- Hello, I've downloaded the VC6 PHP 5.3.0 windows zip (php-5.3.0-nts-Win32-VC6-x86.zip) and I don't see the file php5apache2.dll in it. php5apache.dll is in there, but the apache 2 file isn't. Where can I find this file?
--- End Message ---

Reply via email to