what does two semicolns ';;' do

[larry]

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

I've tried to google it but the text filter seems to remove the
semicolons.

[=?UTF-8?B?SXbDoW4gU8OhbmNoZXogT3J0ZWdh?=]

la***@portcommodore.com wrote:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

The two semicolons are *part* of the "for" construct. See any books on C or
C++ about "for" loops.

That means that the initial statement, the break condition and the loop
statement in that loop are the empty statement.

That means that the for loop does not initialize anything when starting,
does not check for any break condition, and does not perform anything at
the end of each loop.

Which means, that's an infinite loop (until it's broken by calling the
break() construct inside the loop)

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

MSN:i_*************************@hotmail.com
Jabber:iv*********@jabber.org ; iv*********@kdetalk.net

[Jerry Stuckle]

la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

I've tried to google it but the text filter seems to remove the
semicolons.

Look up a for loop in the PHP doc. Three expressions, separated by
semicolons. In this case, the expressions are null (which is also valid).

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

[jmark]

On Jun 28, 1:43*pm, [e-mail] wrote:

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ * * // for([two semicolons){

what is the function of the two semicolons? *loop until break?

I've tried to google it but the text filter seems to remove the
semicolons.

yes, that's an infinite loop

[jimp]

la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).
--
Jim Pennino

Remove .spam.sux to reply.

[larry]

I figured that out soon after I posted it, not very apparent what it
it does though.

Thanks

[sheldonlg]

la***@portcommodore.com wrote:

I figured that out soon after I posted it, not very apparent what it
it does though.

Thanks

Au contraire! It was **immediately** apparent to anyone who has done
any C, C++, Java, etc. coding.

[Thomas Mlynarczyk]

ji**@specsol.spam.sux.com schrieb:

AIR for(;;) is slightly more efficient/faster than while(1).

How come? Isn't

for ( init; cond; after ) { stuff }

just syntactic sugar for

init; while ( cond ) { stuff; after }

and should therefore internally be the same?

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

[=?UTF-8?B?SXbDoW4gU8OhbmNoZXogT3J0ZWdh?=]

Thomas Mlynarczyk wrote:

ji**@specsol.spam.sux.com schrieb:

>AIR for(;;) is slightly more efficient/faster than while(1).

How come? Isn't [for] just syntactic sugar for [while] and should
therefore internally be the same?

It really depends on how your compiler optimizes jumps and boolean
expressions. A good compiler will know that both while(1) and for(;;) are
infinite loops and will translate them to non-conditional jumps in
assembler, effectively rendering them the same.

A bad compiler won't.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Cristo ha muerto por nuestros pecados, asÃ* que no vamos a frustrarle.

[jimp]

Iv??n S??nchez Ortega <[e-mail]:

Thomas Mlynarczyk wrote:

ji**@specsol.spam.sux.com schrieb:

AIR for(;;) is slightly more efficient/faster than while(1).

How come? Isn't [for] just syntactic sugar for [while] and should
therefore internally be the same?

It really depends on how your compiler optimizes jumps and boolean
expressions. A good compiler will know that both while(1) and for(;;) are
infinite loops and will translate them to non-conditional jumps in
assembler, effectively rendering them the same.

A bad compiler won't.

And some compilers will recognize one but not the other.
--
Jim Pennino

Remove .spam.sux to reply.

[larry]

On Jun 29, 4:20 am, sheldonlg <sheldonlgwrote:

[e-mail] wrote:

I figured that out soon after I posted it, not very apparent what it
it does though.

Thanks

Au contraire! It was **immediately** apparent to anyone who has done
any C, C++, Java, etc. coding.

Ya got me, I went from BASIC->6502 assembly->foxBase->PHP With a
little chipmunk BASIC along the way. :-)

Larry

[AnrDaemon]

Greetings, Ivan Sanchez Ortega.
In reply to Your message dated Saturday, June 28, 2008, 23:01:00,

>for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

The two semicolons are *part* of the "for" construct. See any books on C or
C++ about "for" loops.

That means that the initial statement, the break condition and the loop
statement in that loop are the empty statement.

That means that the for loop does not initialize anything when starting,
does not check for any break condition, and does not perform anything at
the end of each loop.

Which means, that's an infinite loop (until it's broken by calling the
break() construct inside the loop)

Ridiculous usage of the language construct...
Why not use

while(true){ ... }

then?
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[Tim Roberts]

ji**@specsol.spam.sux.com wrote:

>la***@portcommodore.com wrote:

>I am looking at some code which process an uploaded file and it has
loops like:

>for(;;){ // for([two semicolons){

>what is the function of the two semicolons? loop until break?

Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).

That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[jimp]

Tim Roberts <ti**@probo.comwrote:

ji**@specsol.spam.sux.com wrote:

la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).

That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".

True if there is optimization going on.
--
Jim Pennino

Remove .spam.sux to reply.

[Michael Fesser]

..oO(AnrDaemon)

>Greetings, Ivan Sanchez Ortega.

>Which means, that's an infinite loop (until it's broken by calling the
break() construct inside the loop)

Ridiculous usage of the language construct...
Why not use

while(true){ ... }

then?

Pest or cholera. You also have to use a break to leave the while loop.
IMHO infinite loops are always ugly and bad coding style, regardless of
how you code them.

Micha

[Tim Streater]

In article <S9******************************@giganews.com>,
sheldonlg <sheldonlgwrote:

la***@portcommodore.com wrote:

I figured that out soon after I posted it, not very apparent what it
it does though.

Thanks

Au contraire! It was **immediately** apparent to anyone who has done
any C, C++, Java, etc. coding.

And supposing they haven't? Or supposing this question had been posed on
a C newsgroup, your response would have been *what* exactly?

[Tim Streater]

In article <iv********************************@4ax.com>,
Michael Fesser <ne*****@gmx.dewrote:

.oO(AnrDaemon)

Greetings, Ivan Sanchez Ortega.

Which means, that's an infinite loop (until it's broken by calling the
break() construct inside the loop)

Ridiculous usage of the language construct...
Why not use

while(true){ ... }

then?

Pest or cholera. You also have to use a break to leave the while loop.
IMHO infinite loops are always ugly and bad coding style, regardless of
how you code them.

Not necessarily. I would always use while (true), as then you make
explicit what you are doing. Secondly, sure you have to break out of the
loop. But suppose there's a number of different reasons to do so? You're
not necessarily going to be able to choose one as the "main driver" of
the loop, which ought then to migrate into the loop construct?

[Michael Fesser]

..oO(Tim Streater)

>In article <iv********************************@4ax.com>,
Michael Fesser <ne*****@gmx.dewrote:

>Pest or cholera. You also have to use a break to leave the while loop.
IMHO infinite loops are always ugly and bad coding style, regardless of
how you code them.

Not necessarily. I would always use while (true), as then you make
explicit what you are doing. Secondly, sure you have to break out of the
loop. But suppose there's a number of different reasons to do so? You're
not necessarily going to be able to choose one as the "main driver" of
the loop, which ought then to migrate into the loop construct?

You could still find a better way to express the loop condition, even if
it's just a variable:

while (!$workIsDone) {
...
}

I admit that I also use break/continue from time to time, but I try to
avoid them because they often lead to hard to understand spaghetti code.
There's almost always a better way to structure the code.

Micha

[sheldonlg]

Tim Streater wrote:

In article <S9******************************@giganews.com>,
sheldonlg <sheldonlgwrote:

>la***@portcommodore.com wrote:

>>I figured that out soon after I posted it, not very apparent what it
it does though.

Thanks

Au contraire! It was **immediately** apparent to anyone who has done
any C, C++, Java, etc. coding.

And supposing they haven't? Or supposing this question had been posed on
a C newsgroup, your response would have been *what* exactly?

It would have been RTFM or take course like C-101. This question was on
the level of "What is a for loop?".

[sheldonlg]

Michael Fesser wrote:

.oO(Tim Streater)

>In article <iv********************************@4ax.com>,
Michael Fesser <ne*****@gmx.dewrote:

>>Pest or cholera. You also have to use a break to leave the while loop.
IMHO infinite loops are always ugly and bad coding style, regardless of
how you code them.

Not necessarily. I would always use while (true), as then you make
explicit what you are doing. Secondly, sure you have to break out of the
loop. But suppose there's a number of different reasons to do so? You're
not necessarily going to be able to choose one as the "main driver" of
the loop, which ought then to migrate into the loop construct?

You could still find a better way to express the loop condition, even if
it's just a variable:

while (!$workIsDone) {
...
}

I admit that I also use break/continue from time to time, but I try to
avoid them because they often lead to hard to understand spaghetti code.
There's almost always a better way to structure the code.

Micha

I agree. I never use while(true) or while(1), but opt for the
while ($somecondition) when I have to do this. That way there is an
explicit test at the top of the loop and I don't have to use "break". I
feel that the code is more readable if you can tell right away where the
next line is.

[Tim Streater]

In article <g4********************************@4ax.com>,
Michael Fesser <ne*****@gmx.dewrote:

.oO(Tim Streater)

In article <iv********************************@4ax.com>,
Michael Fesser <ne*****@gmx.dewrote:

Pest or cholera. You also have to use a break to leave the while loop.
IMHO infinite loops are always ugly and bad coding style, regardless of
how you code them.

Not necessarily. I would always use while (true), as then you make
explicit what you are doing. Secondly, sure you have to break out of the
loop. But suppose there's a number of different reasons to do so? You're
not necessarily going to be able to choose one as the "main driver" of
the loop, which ought then to migrate into the loop construct?

You could still find a better way to express the loop condition, even if
it's just a variable:

while (!$workIsDone) {
...
}

I admit that I also use break/continue from time to time, but I try to
avoid them because they often lead to hard to understand spaghetti code.
There's almost always a better way to structure the code.

Here's some code from a simple app I am working on:

foreach ($attstrs as $nextatt)
{
if ($nextatt=='') continue;
$nextatt = "/Volumes/" . str_replace (":", "/", $nextatt);
$handle2 = fopen ($nextatt, "rb");
if ($handle2===false)
{
echo "Error - could not open attachment:\n '" . $nextatt .
"'\n";
continue;
}

...

}

Two continues in there. The alternative is to nest the code deeper,
something I avoid like the plague.

[Peter H. Coffin]

On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:

Tim Roberts <ti**@probo.comwrote:

>ji**@specsol.spam.sux.com wrote:

>la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).

>That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".

True if there is optimization going on.

Okay:

That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".

Better?

--
91. I will not ignore the messenger that stumbles in exhausted and obviously
agitated until my personal grooming or current entertainment is finished.
It might actually be important.
--Peter Anspach's list of things to do as an Evil Overlord

[Michael Fesser]

..oO(sheldonlg)

>Tim Streater wrote:

>And supposing they haven't? Or supposing this question had been posed on
a C newsgroup, your response would have been *what* exactly?

It would have been RTFM or take course like C-101. This question was on
the level of "What is a for loop?".

But only in C and the languages that were influenced by it. Other
languages use a totally different syntax (for example Pascal and its
derivates).

Micha

[jimp]

Peter H. Coffin <he*****@ninehells.comwrote:

On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:

Tim Roberts <ti**@probo.comwrote:

ji**@specsol.spam.sux.com wrote:
la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).

That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".

True if there is optimization going on.

Okay:

That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".

Better?

You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.
--
Jim Pennino

Remove .spam.sux to reply.

[Peter H. Coffin]

On Mon, 30 Jun 2008 15:05:02 GMT, ji**@specsol.spam.sux.com wrote:

Peter H. Coffin <he*****@ninehells.comwrote:

>On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:

Tim Roberts <ti**@probo.comwrote:
ji**@specsol.spam.sux.com wrote:
la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).

That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".

True if there is optimization going on.

>Okay:

> That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".

>Better?

You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.

Exactly. Since we're presuming we don't know how clever the compiler is
exactly, it's therefore silly to claim that for(;;) is slightly more
efficient/faster than while(1). The compiler could handle both the same
way, in which case they'd be the same speed in execution.

--
Liberty, equality, diversity. Pick any two.

[jimp]

Peter H. Coffin <he*****@ninehells.comwrote:

On Mon, 30 Jun 2008 15:05:02 GMT, ji**@specsol.spam.sux.com wrote:

Peter H. Coffin <he*****@ninehells.comwrote:

On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:
Tim Roberts <ti**@probo.comwrote:
ji**@specsol.spam.sux.com wrote:
la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).

That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".

True if there is optimization going on.

Okay:

That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".

Better?

You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.

Exactly. Since we're presuming we don't know how clever the compiler is
exactly, it's therefore silly to claim that for(;;) is slightly more
efficient/faster than while(1). The compiler could handle both the same
way, in which case they'd be the same speed in execution.

Except in the terms of the original posting I seem to recall reading
somewhere that in the specific case of PHP for(;;) is slightly more
efficient.

I could, however, be experiencing a flash back from the 60's and be
wrong about that.
--
Jim Pennino

Remove .spam.sux to reply.

[larry]

In all the examples of for, there were values other then just ;;, it
was a valid question. In other languages such a statement with nulls
instead of variables and values would rightly cause errors:

for = to : next

[The Natural Philosopher]

ji**@specsol.spam.sux.com wrote:

Peter H. Coffin <he*****@ninehells.comwrote:

>On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:

>>Tim Roberts <ti**@probo.comwrote:
ji**@specsol.spam.sux.com wrote:
la***@portcommodore.com wrote:
>
>I am looking at some code which process an uploaded file and it has
>loops like:
>for(;;){ // for([two semicolons){
>what is the function of the two semicolons? loop until break?
Yeah, same as while (1) {.
>
AIR for(;;) is slightly more efficient/faster than while(1).
That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".
True if there is optimization going on.

>Okay:

> That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".

>Better?

You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.

And that can screw you if you are - say - using i as an external global
variable, and setting it as a flag via an interrupt service routine.

Ther is some construct in C - is a it 'volatile'? - to tell the compiler
'this variable may change even if you cant see hwo' IIRC.

And it might have stuffed the value in an inaccessible register as well.

[Tim Streater]

In article <12***************@proxy00.news.clara.net>,
The Natural Philosopher <[e-mail]:

ji**@specsol.spam.sux.com wrote:

Peter H. Coffin <he*****@ninehells.comwrote:

On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:
Tim Roberts <ti**@probo.comwrote:
ji**@specsol.spam.sux.com wrote:
la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:
for(;;){ // for([two semicolons){
what is the function of the two semicolons? loop until break?
Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).
That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".
True if there is optimization going on.

Okay:

That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".

Better?

You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.

And that can screw you if you are - say - using i as an external global
variable, and setting it as a flag via an interrupt service routine.

Ther is some construct in C - is a it 'volatile'? - to tell the compiler
'this variable may change even if you cant see hwo' IIRC.

And it might have stuffed the value in an inaccessible register as well.

Presumably you could put it in a struct. Otherwise, yes, there's a
danger the variable gets optimised away.

[Erwin Moller]

Michael Fesser schreef:

.oO(Tim Streater)

>In article <iv********************************@4ax.com>,
Michael Fesser <ne*****@gmx.dewrote:

>>Pest or cholera. You also have to use a break to leave the while loop.
IMHO infinite loops are always ugly and bad coding style, regardless of
how you code them.

Not necessarily. I would always use while (true), as then you make
explicit what you are doing. Secondly, sure you have to break out of the
loop. But suppose there's a number of different reasons to do so? You're
not necessarily going to be able to choose one as the "main driver" of
the loop, which ought then to migrate into the loop construct?

You could still find a better way to express the loop condition, even if
it's just a variable:

while (!$workIsDone) {
...
}

I admit that I also use break/continue from time to time, but I try to
avoid them because they often lead to hard to understand spaghetti code.
There's almost always a better way to structure the code.

Micha

I totally utterly agree with Misha here.

If you write code try to make the logic/structure clear by picking nice
named variables, like $workIsDone.

What could possibly be the advantage of leaving them out?
Some misguided newbies might say 'for speed'.

Good programmers write clean code, not code that is 0.01% faster, but
clean code.
It is always a pleasure to read over code written by a programmer that
put some effort in it to make thing clear and simple.
It is a horror to read over (often buggy) code written by would-be
programmers that is aimed at speed (by sacrifying variables that help
understand the logic), or people trying to keep the sourcefiles as small
as possible.

Just my 2 cent.

Regards,
Erwin Moller

[sheldonlg]

Erwin Moller wrote:

>
Michael Fesser schreef:

>.oO(Tim Streater)

>>In article <iv********************************@4ax.com>,
Michael Fesser <ne*****@gmx.dewrote:

Pest or cholera. You also have to use a break to leave the while loop.
IMHO infinite loops are always ugly and bad coding style, regardless of
how you code them.
Not necessarily. I would always use while (true), as then you make
explicit what you are doing. Secondly, sure you have to break out of
the loop. But suppose there's a number of different reasons to do so?
You're not necessarily going to be able to choose one as the "main
driver" of the loop, which ought then to migrate into the loop
construct?

You could still find a better way to express the loop condition, even if
it's just a variable:

while (!$workIsDone) {
...
}

I admit that I also use break/continue from time to time, but I try to
avoid them because they often lead to hard to understand spaghetti code.
There's almost always a better way to structure the code.

Micha

I totally utterly agree with Misha here.

If you write code try to make the logic/structure clear by picking nice
named variables, like $workIsDone.

What could possibly be the advantage of leaving them out?
Some misguided newbies might say 'for speed'.

Good programmers write clean code, not code that is 0.01% faster, but
clean code.
It is always a pleasure to read over code written by a programmer that
put some effort in it to make thing clear and simple.
It is a horror to read over (often buggy) code written by would-be
programmers that is aimed at speed (by sacrifying variables that help
understand the logic), or people trying to keep the sourcefiles as small
as possible.

Just my 2 cent.

Regards,
Erwin Moller

Add mine to make it 4 cents.

[Jerry Stuckle]

Tim Streater wrote:

In article <12***************@proxy00.news.clara.net>,
The Natural Philosopher <[e-mail]:

>ji**@specsol.spam.sux.com wrote:

>>Peter H. Coffin <he*****@ninehells.comwrote:
On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:
Tim Roberts <ti**@probo.comwrote:
>ji**@specsol.spam.sux.com wrote:
>>la***@portcommodore.com wrote:
>>>
>>>I am looking at some code which process an uploaded file and it has
>>>loops like:
>>>for(;;){ // for([two semicolons){
>>>what is the function of the two semicolons? loop until break?
>>Yeah, same as while (1) {.
>>>
>>AIR for(;;) is slightly more efficient/faster than while(1).
>That's silly. Think about it for a moment. How on earth could that
>possibly be true? Both statements translate to exactly one assembly
>instruction: a "jmp".
True if there is optimization going on.
Okay:
That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".
Better?
You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.

And that can screw you if you are - say - using i as an external global
variable, and setting it as a flag via an interrupt service routine.

Ther is some construct in C - is a it 'volatile'? - to tell the compiler
'this variable may change even if you cant see hwo' IIRC.

And it might have stuffed the value in an inaccessible register as well.

Presumably you could put it in a struct. Otherwise, yes, there's a
danger the variable gets optimised away.

Nope, if C the test could be optimized away, even if it's in a
structure. The people who write the optimizers are getting pretty good
at finding ways to make the code run smaller and faster. But they need
to because of the bloat caused by inefficient graphics and other system
code.

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

[Tim Streater]

In article <g4**********@registered.motzarella.org>,
Jerry Stuckle <js*******@attglobal.netwrote:

Tim Streater wrote:

In article <12***************@proxy00.news.clara.net>,
The Natural Philosopher <[e-mail]:

ji**@specsol.spam.sux.com wrote:
Peter H. Coffin <he*****@ninehells.comwrote:
On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:
Tim Roberts <ti**@probo.comwrote:
ji**@specsol.spam.sux.com wrote:
>la***@portcommodore.com wrote:
>>
>>I am looking at some code which process an uploaded file and it has
>>loops like:
>>for(;;){ // for([two semicolons){
>>what is the function of the two semicolons? loop until break?
>Yeah, same as while (1) {.
>>
>AIR for(;;) is slightly more efficient/faster than while(1).
That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".
True if there is optimization going on.
Okay:
That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".
Better?
You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.
And that can screw you if you are - say - using i as an external global
variable, and setting it as a flag via an interrupt service routine.

Ther is some construct in C - is a it 'volatile'? - to tell the compiler
'this variable may change even if you cant see hwo' IIRC.

And it might have stuffed the value in an inaccessible register as well.

Presumably you could put it in a struct. Otherwise, yes, there's a
danger the variable gets optimised away.

Nope, if C the test could be optimized away, even if it's in a
structure. The people who write the optimizers are getting pretty good
at finding ways to make the code run smaller and faster. But they need
to because of the bloat caused by inefficient graphics and other system
code.

Fairy nuff. It's 20 years since I wrote any C :-)

[Tim Streater]

In article <g4**********@registered.motzarella.org>,
Jerry Stuckle <js*******@attglobal.netwrote:

Tim Streater wrote:

In article <12***************@proxy00.news.clara.net>,
The Natural Philosopher <[e-mail]:

ji**@specsol.spam.sux.com wrote:
Peter H. Coffin <he*****@ninehells.comwrote:
On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:
Tim Roberts <ti**@probo.comwrote:
ji**@specsol.spam.sux.com wrote:
>la***@portcommodore.com wrote:
>>
>>I am looking at some code which process an uploaded file and it has
>>loops like:
>>for(;;){ // for([two semicolons){
>>what is the function of the two semicolons? loop until break?
>Yeah, same as while (1) {.
>>
>AIR for(;;) is slightly more efficient/faster than while(1).
That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".
True if there is optimization going on.
Okay:
That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".
Better?
You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.
And that can screw you if you are - say - using i as an external global
variable, and setting it as a flag via an interrupt service routine.

Ther is some construct in C - is a it 'volatile'? - to tell the compiler
'this variable may change even if you cant see hwo' IIRC.

And it might have stuffed the value in an inaccessible register as well.

Presumably you could put it in a struct. Otherwise, yes, there's a
danger the variable gets optimised away.

Nope, if C the test could be optimized away, even if it's in a
structure. The people who write the optimizers are getting pretty good
at finding ways to make the code run smaller and faster. But they need
to because of the bloat caused by inefficient graphics and other system
code.

Fairy nuff. It's 20 years since I wrote any C :-)

[Peter H. Coffin]

On Mon, 30 Jun 2008 16:15:01 GMT, ji**@specsol.spam.sux.com wrote:

Peter H. Coffin <he*****@ninehells.comwrote:

>On Mon, 30 Jun 2008 15:05:02 GMT, ji**@specsol.spam.sux.com wrote:

Peter H. Coffin <he*****@ninehells.comwrote:
On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:
Tim Roberts <ti**@probo.comwrote:
ji**@specsol.spam.sux.com wrote:
la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:

for(;;){ // for([two semicolons){

what is the function of the two semicolons? loop until break?

Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).

That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".

True if there is optimization going on.

Okay:

That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".

Better?

You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.

>Exactly. Since we're presuming we don't know how clever the compiler is
exactly, it's therefore silly to claim that for(;;) is slightly more
efficient/faster than while(1). The compiler could handle both the same
way, in which case they'd be the same speed in execution.

Except in the terms of the original posting I seem to recall reading
somewhere that in the specific case of PHP for(;;) is slightly more
efficient.

Clearly, that will depend on the compiler, neh?

(I think we are now in an infinate loop ourselves...)

--
"It's 106 light-years to Chicago, we've got a full chamber of anti-matter,
a half a pack of cigarettes, it's dark, and we're wearing visors."
"Engage."

[=?UTF-8?B?SXbDoW4gU8OhbmNoZXogT3J0ZWdh?=]

Peter H. Coffin wrote:

(I think we are now in an infinate loop ourselves...)

Don't worry, I'm sure there will be somebody that will optimize us.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Perilous to all of us are the devices of an art deeper than we ourselves
possess.
-- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]

[AnrDaemon]

Greetings, Michael Fesser.
In reply to Your message dated Monday, June 30, 2008, 15:35:13,

>>Which means, that's an infinite loop (until it's broken by calling the
break() construct inside the loop)

Ridiculous usage of the language construct...
Why not use

while(true){ ... }

then?

Pest or cholera. You also have to use a break to leave the while loop.
IMHO infinite loops are always ugly and bad coding style, regardless of
how you code them.

True word, but sometimes it's usable (but must be avoided as possible).
If that's a required way to work, while(true) will be much more understandable
by anyone who will read the code in future.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[jimp]

The Natural Philosopher <[e-mail]:

ji**@specsol.spam.sux.com wrote:

Peter H. Coffin <he*****@ninehells.comwrote:

On Mon, 30 Jun 2008 03:35:01 GMT, ji**@specsol.spam.sux.com wrote:
Tim Roberts <ti**@probo.comwrote:
ji**@specsol.spam.sux.com wrote:
la***@portcommodore.com wrote:

I am looking at some code which process an uploaded file and it has
loops like:
for(;;){ // for([two semicolons){
what is the function of the two semicolons? loop until break?
Yeah, same as while (1) {.

AIR for(;;) is slightly more efficient/faster than while(1).
That's silly. Think about it for a moment. How on earth could that
possibly be true? Both statements translate to exactly one assembly
instruction: a "jmp".
True if there is optimization going on.

Okay:

That's silly. Think about it for a moment. How on earth could that
possibly be reliably true? Both statements can easily translate to
exactly one assembly instruction: a "jmp".

Better?

You're missing the point.

While it is obviously true that whatever is translating the code COULD
do that, not all translators/compilers actually DO that.

Here's another case:

i=1;

while (i) {
// i never changes
}

Some compilers/translators will recognize this is an infinite loop
and some won't.

It all bepends on how clever the compiler/translator is.

And that can screw you if you are - say - using i as an external global
variable, and setting it as a flag via an interrupt service routine.

Ther is some construct in C - is a it 'volatile'? - to tell the compiler
'this variable may change even if you cant see hwo' IIRC.

And it might have stuffed the value in an inaccessible register as well.

Has everyone lost sight of the fact that this is a PHP group?

Does anyone have a clue what PHP actually does with stuff like this?

--
Jim Pennino

Remove .spam.sux to reply.

[Tim Roberts]

ji**@specsol.spam.sux.com wrote:

>
Has everyone lost sight of the fact that this is a PHP group?

Yeah, that occurred to be about 15 seconds after I posted my original
reply.

>Does anyone have a clue what PHP actually does with stuff like this?

That's a good question, and now I'm curious. Python has a way to dump the
byte code it generates in a relatively human-readable form. Does PHP have
the same thing?
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.