Hacker News

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

There is a reason postfix is the idiomatic way in C, it is the correct choice most of the time.

It's just spacing. X-- > 0 and X --> 0 are the same thing in C.

There is nothing clearer about your way unless one is in the few first chapters of the K&R's book.

'while (i--)k is a shortcut, which might seem terse when one first encounters it, it is a well-established and trivial to understand construct. On the other hand, your embellishment only adds pointless friction when reading the code.

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

I know. This does not make it a bad choice.

Unsigned integer overflow is well defined, though. Not something that should be sanitized. A lot of code out there relies on it.

That looks like the brainfuck mandelbrot set by Erik Bosman, but the example is missing the header line with the credit. The one I saw came from here:

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)

Does work with ssize_t, just not necessary.

You should always check the compiled assembly with Compiler Explorer because compilers sometimes avoid certain optimizations for convoluted reasons, which are hard to predict.

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

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?

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.

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.

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