Hopefully your compiler would optimize the two to the same thing.
Ok, I was hoping it would be that. But just in case, you know... like, if doing the while might require a check of some sort while the for would just loop without checking anything, maybe the for would be marginally more efficient or something. I'm about to grab a disassembler from somewhere though, I guess I'll have to see if there's any difference myself (even though I won't have a clue what's going on in the assembly :D)
For what it's worth, I actually have encountered a case in which
while(1) evaluated a condition rather than looping unconditionally. Granted, this was in C on an embedded platform nowhere near a PC. But after all, the code
while(1) does specify a condition.
I think the real point in this is why? Why write something that will
hopefully be optimized away, rather than writing another way that
will be correct no hoping required, no optimizations needed?
I used to be a
while(1) person. I have since a found reason to prefer
for( ;; ).
Also, my linter doesn't care for the
while(1) and tells me wherever I have one: "
test.c 5: [Info 716] while(1) ... ". And the following is the message description:
716 while(1) ... -- A construct of the form while(1) ... was found. Whereas this represents a constant in a context expecting a Boolean, it may reflect a programming policy whereby infinite loops are prefixed with this construct. Hence it is given a separate number and has been placed in the informational category. The more conventional form of infinite loop prefix is for(;;)