As someone who only writes C or C++ occasionally, I'd consider this a good submission for an obfuscated C contest.
It really does look simple at first glance.
Then you start to wonder what the stop condition is.
Then you realize the i-- is the stop condition.
Then you wonder how the whole thing works at all.
(The description explained the trick well, and the construct makes sense once you understand it, but I still think this is one example of something that is "too simple" and becomes cryptic)
After all the stuff you hear about undefined behavior, I'm also honestly surprised that wraparound on unsigned types is not undefined behavior.
Hard disagree. Obfuscated code is code that does something different from what it seems to be doing at first glance. This backwards loop does exactly the thing you'd expect it to do - in code review I'd only double-check whether it's actually correct - I can see someone making a mistake here and creating an infinite loop.
> I'm also honestly surprised that wraparound on unsigned types is not undefined behavior.
> Now your index variable is signed, which can cause problems when used in expressions due to C's conversion rules.
I don't see this. What problems would those be?
> ssize_t is a POSIX thing so you'd have to define it yourself on windows.
True. But I think "int" would be the right choice anyway in almost all case.
> If your type is 32 bit, you run into promotion problems and might even run into truncation problems.
What promotion problems? If your loop exceeds 2G than yes, you run into overflow (not for backwards loop though). But with a signed type you can automatically get a trap or diagnostic for overflow. This is far easier to debug and protect against compared to mistakes with unsigned types.
I was unclear in the article, but in my defense I wrote it in a hurry on the couch after seeing the convoluted backwards loop an llm had extruded. I meant if you are actually doing something with the index variable other than indexing. Mixing signed and unsigned types, possibly of different sizes, has surprising behavior to many programmers who don’t have the “usual arithmetic conversions” memorized. If you’re working in size_t the result simplifies: everything becomes size_t. And you generally have size_t anyway as you’re using the result of sizeof or an allocation size passed to your allocation function.
In general I want to avoid signed types for counts and sizes as then you have to consider both boundary conditions which is easy to mess up.
I agree that mixing signed and unsigned types creates friction. After trying to use unsigned for sizes and indices for a while, I changed my mind and now use signed types almost everywhere, except for modulo arithmetic and bit masks, and I found this removes all problems I had before.
I don't think the usual arithmetic conversions are very problematic, IMHO there is a lot of FUD about this. The rule is also very simple: "Operands are converted to the higher ranked type but at least to the rank of int, and to the signed type if it covers all values of both types and otherwise to the unsigned version." This is the complete rule.
I like the your final version, but it is a bit too clever for my taste.
Oh I remember this from the classic SO post, but it was just presented as a funny trick. I never realized that it solves the issue mentioned in the article and there is a legitimate use-case for post-decrement in the comparison itself.
if `i` ever gets modified inside the loop, and skips 0 (e.g., got decremented twice when it is at 1), then you might end up with an infinite loop?
Usually, this won't happen of course, but because `i` is not declared inside a for-loop, it must have been declared outside, and thus might even look like a regular variable that could be used by some "clever" coding to multipurpose it!
In any case, it's a niche worry i have, so i usually don't do it if i know there's a for loop that would do.
I don't think it's too clever at all. Notably it works with both signed and unsigned i. Frankly if I see anyone doing anything other than this, they're wrong.
The part I like is starting from the count rather than count-1. If n is 0, `i --> 0` never enters. Do `size_t i = n - 1` and a zero-length array wraps to SIZE_MAX first, which is the case that actually runs off the front.
That's the price of innovation, I guess; before C invented its "for"-loop, other languages had their equivalents generally looking like this:
FOR var = start [DOWN] TO end BY step DO ... END
No custom increment expressions, and "step" even usually was only allowed to be a constant (in which case, the language usually didn't have DOWN specifier and used the step's sign instead). Then Dennis Ritchie invented C, and ditched the traditional "do"-loop (Fortran started that construct with DO, so it was called DO loop; Algol used FOR instead, but most people preferred the Fortran's nomenclature... until C came to dominate, but that wouldn't happen for yet another 20 years) in favour of his invention because he felt that easily iterating through linked lists or strings was a much more pressing concern:
His final solution is so tricky. I needed to re-read it a few times to understand the trick of using post decrement in the for loop condition. Personally, I would never write code like that. I would always find a way to use ssize_t.
This part was an interesting requirement:
> ssize_t is a POSIX thing so you'd have to define it yourself on windows.
That seems like a lot of mental gymnastics to avoid this very simple macro:
This is why I prefer to use C++ and its reversed iterators. The rbegin and rend accessors are there in the containers from the beginning. It’s less error prone than the C version using indices. (Of course some situations require me to use indices, so I do use the i-->0 trick, but it is much rarer.)
For the uninformed: counting backwards in a for loop is faster because comparing an unsigned integer against 0 is generally faster than comparing it against any other value.
It also says not to use `for (i >= 0)` because any unsigned integer is >= 0, and the loop will never end.
You should always check the compiled assembly with Compiler Explorer because compilers sometimes avoid certain optimizations for convoluted reasons, which are hard to predict.
> ...counting backwards in a for loop is faster...
Maybe in 1990 ;)
(it's one of many cargo cult wisdom snippets that have become mostly obsolete once C compilers got proper optimizer passes and CPUs got all sorts of pipeling tricks)
> For the uninformed: counting backwards in a for loop is faster because comparing an unsigned integer against 0 is generally faster than comparing it against any other value.
No it's not. It generally makes no difference at all.
If you disagree, I dare you to write a benchmark that demonstrates a difference between forward and backward iteration on a modern CPU.
Hmm. I think both of you are both right and wrong!
That is, I claim that while it is no faster to execute a comparison against zero, it still can be faster to finish a loop at zero. This is because internal to the processor, the comparison and the branch are two separate ops. The comparison essentially does an arithmetic operation that sets a flag but throws away the result, and then the branch acts on it.
But if you finish at zero, the flag you are using is already set by the decrement, so no additional comparison op is necessary. Now normally this doesn't matter, since the processor is multiscalar with sufficient execution ports to fit in an extra comparison with no increase in total cycles spent. But in a tiny and highly optimized loop, occasionally you can get about 20% gain from having one fewer op to execute.
Getting this to actually happen can be complicated because modern processors do op-fusion that can "fuse" the CMP and branch back into something that can be executed on a single port. But DEC-JNZ can be fused too, which still gives it an advantage. More details on this here: https://chipswiki.org/Macro-operation_fusion
I quote from "Optimizing Software in C++" by Agner Fog:
"Comparing an integer to zero is sometimes more efficient than comparing it to any other number. Therefore, it is slightly more efficient to make a loop count down to zero than to make it count up to some positive value, n. But not if the loop counter is used as an array index. The data cache is optimized for accessing arrays forwards, not backwards."
Yet that text was written for older CPUs. Modern CPUs are better at prefetching backwards access patterns, but if you try a microbenchmark with backwards array traversal, you may get misleading results.
Eh I don't know, the straightforward solution is still to use a signed loop counter (and signed indices) and only ever use unsigned integer types for bit twiddling. Also, enable `-Wsign-conversion` (it's not in -Wall -Wextra) to catch all the places where the compiler implicitly converts between signed and unsigned behind your back.
C doesn't have an opinion, it allows negative indexing just fine when the index is a signed type (indexing-syntax is just syntax-sugar for pointer arithmetic).
Well, the array indices are allowed to be any sorts of integers, and the standard is worded in such a way that such addition must work correctly without overflowing — provided, of course, that the array you're indexing into is large enough. So in practice, you're bounded by the width of size_t.
Oh, and did you know that the width of ptrdiff_t is not required to have any relation to the width of size_t? There is even an explicit provision in standard for the case when subtracting two pointers into the same very large array can't fit into ptrdiff_t:
When two pointers are subtracted, both shall point to elements of the same array object, or one past
the last element of the array object; the result is the difference of the subscripts of the two array
elements. The size of the result is implementation-defined, and its type (a signed integer type) is
ptrdiff_t defined in the <stddef.h> header. If the result is not representable in an object of that
type, the behavior is undefined.
So yeah; you should try to work strictly with indices only, they're guaranteed to be correctly addible to pointers no matter the sizes of your arrays.
I myself write loops with goto. It gives precise control, allows to reuse the knowledge gained from operations inside the loop, avoids artificial "while true" and is generally more convenient. It is also makes the language simpler as you can forget 4 to 5 loop-related keywords and hard-to parse operators designed primarily to look nice in loop conditions while also modifying their arguments.
As someone who only writes C or C++ occasionally, I'd consider this a good submission for an obfuscated C contest.
It really does look simple at first glance.
Then you start to wonder what the stop condition is.
Then you realize the i-- is the stop condition.
Then you wonder how the whole thing works at all.
(The description explained the trick well, and the construct makes sense once you understand it, but I still think this is one example of something that is "too simple" and becomes cryptic)
After all the stuff you hear about undefined behavior, I'm also honestly surprised that wraparound on unsigned types is not undefined behavior.
> I'm also honestly surprised that wraparound on unsigned types is not undefined behavior.
I consider it common knowledge TBH
For a seasoned C developer, I’d agree with you, but parent declares himself
> As someone who only writes C or C++ occasionally
… so I think it’s fair enough to not know such details.
C semantics has a few details that often surprise non-regulars, despite being such a small and simple language.
I don't see this. What problems would those be?
> ssize_t is a POSIX thing so you'd have to define it yourself on windows.
True. But I think "int" would be the right choice anyway in almost all case.
> If your type is 32 bit, you run into promotion problems and might even run into truncation problems.
What promotion problems? If your loop exceeds 2G than yes, you run into overflow (not for backwards loop though). But with a signed type you can automatically get a trap or diagnostic for overflow. This is far easier to debug and protect against compared to mistakes with unsigned types.
In general I want to avoid signed types for counts and sizes as then you have to consider both boundary conditions which is easy to mess up.
I don't think the usual arithmetic conversions are very problematic, IMHO there is a lot of FUD about this. The rule is also very simple: "Operands are converted to the higher ranked type but at least to the rank of int, and to the signed type if it covers all values of both types and otherwise to the unsigned version." This is the complete rule.
I like the your final version, but it is a bit too clever for my taste.
It's the worst choice. int is 32-bit on most 64-bit architecture/compiler-versions that matter.
https://stackoverflow.com/questions/1642028/what-is-the-oper...
Usually, this won't happen of course, but because `i` is not declared inside a for-loop, it must have been declared outside, and thus might even look like a regular variable that could be used by some "clever" coding to multipurpose it!
In any case, it's a niche worry i have, so i usually don't do it if i know there's a for loop that would do.
Reading code should be enjoyable.
(Hi Ken!)
I would do it exactly like you suggest, but using an explicitly sized type like uint32_t instead.
If I write firmware or low-level code, I almost exclusively use integers with explicit bitwidth.
This part was an interesting requirement:
That seems like a lot of mental gymnastics to avoid this very simple macro: Read about the Win32 macro SSIZE_T here: https://learn.microsoft.com/en-us/windows/win32/winprog/wind...To me, this solution is more readable and maintainable:
Alternatively, you can use a while loop where the condition appears at the end of the loop:http://maulingmonkey.com/brainfuck/
https://github.com/thaliaarchi/bfcorpus/blob/main/ebosman/ma...
Be sure to check out other files in that directory for how the program is assembled.
(Erik Bosman's mandelbrot set is a personal favorite of mine, very useful for benchmarking brainfuck interpreters)
VHDL's array/vector syntax actually works a similar way:
-- gives 0, 1, 2, 3:
for i in 0 to 3 loop
-- gives 3, 2, 1, 0:
for i in 3 downto 0 loop
-- Source - https://stackoverflow.com/a/7642026 -- Posted by Kerrek SB -- Retrieved 2026-10-29, License - CC BY-SA 3.0
For me it does not work because I'd want to use it with values < 0, but the for loop checks for > 0, so I would have to modify that first.
It also says not to use `for (i >= 0)` because any unsigned integer is >= 0, and the loop will never end.
Maybe in 1990 ;)
(it's one of many cargo cult wisdom snippets that have become mostly obsolete once C compilers got proper optimizer passes and CPUs got all sorts of pipeling tricks)
No it's not. It generally makes no difference at all.
If you disagree, I dare you to write a benchmark that demonstrates a difference between forward and backward iteration on a modern CPU.
That is, I claim that while it is no faster to execute a comparison against zero, it still can be faster to finish a loop at zero. This is because internal to the processor, the comparison and the branch are two separate ops. The comparison essentially does an arithmetic operation that sets a flag but throws away the result, and then the branch acts on it.
But if you finish at zero, the flag you are using is already set by the decrement, so no additional comparison op is necessary. Now normally this doesn't matter, since the processor is multiscalar with sufficient execution ports to fit in an extra comparison with no increase in total cycles spent. But in a tiny and highly optimized loop, occasionally you can get about 20% gain from having one fewer op to execute.
Getting this to actually happen can be complicated because modern processors do op-fusion that can "fuse" the CMP and branch back into something that can be executed on a single port. But DEC-JNZ can be fused too, which still gives it an advantage. More details on this here: https://chipswiki.org/Macro-operation_fusion
Now does anyone want to finish the "ground speed readout" routine (https://theaviationgeekclub.com/sr-71-blackbird-pilot-tells-...) by pointing out actually how with modern processors I'm actually wrong too?
"Comparing an integer to zero is sometimes more efficient than comparing it to any other number. Therefore, it is slightly more efficient to make a loop count down to zero than to make it count up to some positive value, n. But not if the loop counter is used as an array index. The data cache is optimized for accessing arrays forwards, not backwards."
Yet that text was written for older CPUs. Modern CPUs are better at prefetching backwards access patterns, but if you try a microbenchmark with backwards array traversal, you may get misleading results.
for (int i = 1; i <= N; i++) {
The safe way to write it is:
(or with size_t instead of int depending on the type of N)TL;DR: "alomost always signed!" :)
Array indices are already signed. This shouldn't be a problem.
Oh, and did you know that the width of ptrdiff_t is not required to have any relation to the width of size_t? There is even an explicit provision in standard for the case when subtracting two pointers into the same very large array can't fit into ptrdiff_t:
So yeah; you should try to work strictly with indices only, they're guaranteed to be correctly addible to pointers no matter the sizes of your arrays.