Hacker News Reader

Comment by gigatexal | Hacker News Reader

The c code examples are odd:

For (;;) … While (condition…) …

Why not use while in both situations, so while(1)… instead of for(;;) ?

The semantics of the for loop with an omitted condition more accurately conveys the intent. "Loop forever", vs. "Loop while true is true". A clever compiler will optimize it to the same machine code, but conceptually the while loop is more complex. It requires understanding what a tautology is, for example.

I’m used to seeing for(;;) in C code but I disagree that it’s conceptually similar - the opposite actually. The for() syntax is already inconsistent with three expressions being interpreted as statement;guard-expression;statement.

There’s no other occasion I can think of where an expression becomes vacuously true by being omitted. If it were conceptually coherent you’d write for(;true;). I guess maybe the reason they made C accept for(;;) but not while() is because while() might confuse a compiler by looking like a function call.

You're arguing syntax, I'm arguing semantics. When the intent is to have the program loop unconditionally, omitting a condition seems more appropriate than providing a tautological condition.

Syntax wise, it doesn't really matter. "for" just happens to be the keyword that allows omitting the condition. "While" effectively means "during which". "For" on the other hand has a significantly more flexible meaning; it seems reasonable to me that the for keyword would be more flexible. Syntax wise, the most explicit thing to have in a language would be a "forever" keyword of some sort.

Even a really stupid compiler is going to map for(;;) and while(1) to the same thing. An unconditional back branch at the end of the block. Anything else would be more work.

> Why not use while in both situations, so while(1)… instead of for(;;) ?

Because some compilers warn that the condition is constant and suggest you rewrite it as for (;;)

Both are common in idiomatic C.

for (;;) is less typing.

Someone made a similar comment on my code recently, is that a generational thing?

for (;;) has always been the idiomatic way to do an infinite loop.

I started programming in C circa 1997, following a brother who started a few years earlier, and always used while(1).

FWIW https://github.com/robohack/ucb-csrg-bsd contains both variants.

Many many decades ago, non-optimising compilers would literally check 1==1 on each iteration of the latter.

Not a problem now.

And why would you need to write while(1==1) and not just while(1)?

You don’t - but the compiler needs to test if 1 is true (so conceptually 1==1) every iteration if it isn’t an optimising compiler.

They lack the code to remove a tautological test.

But approximately all compilers these days are optimising compilers, so don’t worry about it.

Yes that I was questioning the, to me, non-sensical 1==1. Why would you not for the normal form of the tautological statement, And if you don't go for the normal form, why choose 1==1 and not one of the infinite other forms.

> Why would you not for the normal form of the tautological statement

Because normalising is an optimization, and these compilers didn't have any optimisations. That was normal back then. You had a whole separate product that was specifically an 'optimising compiler'. These days that's implicit and we just say 'compiler'.

These days, even -O0 will canonicalise the condition! That's how normalised it is! But I guess this is done during translation to IR, rather than as an 'optimisation'.

https://godbolt.org/z/Eoqs7hxqs

The question is not a question of optimization but readability. Can you honestly say you would let `while (1 + 3 * 5 < 10 + 8 - 5 * 1000)` stand in a code review for a simple infinite loop because "the compiler will optimize it anyway".

You’re confused - nobody is suggesting writing anything but ‘while (1)’ at the source code level. We’re talking about how the compiler implements that, and how internally it needs to do ‘1 == 1’ for each iteration if it doesn’t optimise at all.

We’re talking compiler implementation and optimisation - not coding aesthetics.

That makes little sense. There is no equality check in the generated ASM. A compuler doesn't synthesize 1==1 when a `while(1)` is used. Your link even shows this. There is no `cmp` opcode used. A simple unconditional `jmp` is used.

Are you trolling me?

> Your link even shows this.

Yes the link shows how it doesn't matter today! Because almost all compilers are now 'optimising compilers'!

> There is no `cmp` opcode used. A simple unconditional `jmp` is used.

Oh my god that's the entire point! That's how compilers work now. They always optimise. They didn't used to do that.

The compiler checks the truthiness of the value in the while condition. Modern compilers remove it with either a tautology check, or a shortcut during IR building. They didn't used to do that, so there used to be a cost, which is why people started cargo-culting the for equivalent.

Here's a worked example using a niche compiler with a very different architecture that unusually still doesn't canonicalise during building.

Compare

https://godbolt.org/z/3v3anacM8

and

https://godbolt.org/z/chWjsen4s

See the difference? See the 'cmp eax, 1' and then how it goes away under optimisation?

really "while (1)" is the same as "while (1 != 0)" but it's not really any difference, and as mentioned 1==1 and 1!=0 will be optimised out to the same thing

it's no big deal, just one person's coding style, I've done the same thing for at least 40 years now

I personally prefer ‘for’ for both cases actually ;)

Reply on news.ycombinator.com