Obviously. However, it is an appropriate example if your goal is to teach the intricacies of the C language. You're right that if you provide such an example this early, it could perhaps use some additional commentary.

Not only is that confusingly cutesy, but largeA[i] is a double.

That was the point of the exercise: !! is an idiom to convert to boolean (which happen to be integral in C) and something a C programmer (or JavaScript programmer, for that matter) should be familiar with.

This is flatly untrue on x86 and I suspect many other architectures.

Agreed.

As someone unfamiliar with C - I initially thought it would go on forever. The explanatory text explained why I was wrong and this can be equally parts "clever code" or a "gotcha!" depending how you view it. With your experience you're seeing it as overly clever code. With mine, I'm seeing it as a "gotcha". I don't think it is supporting writing code like that. :)

>The third for appears like it would go on forever, but actually counts down from 9 to 0. In fact, in the next section we will see that “sizes” in C, that is numbers that have type size_t, are never negative.

    for (size_t i = 9; i --> 0; )

    for (int i = 9; i >= 0; i -= 1)

The fewer tricks and patterns you use in C, the higher chance actual bugs have of being caught. Cutesy tricks like "-->" confuse human analysis and gain nothing.

Obviously, I just follow the convention when contributing to an existing project.

The range of indexable array elements is not only constrained by the unsigned type size_t, but also by the signed type ptrdiff_t, so you could always go with the latter instead of the non-ISO ssize_t.

At least it's not

    for (size_t i = 9; i >= 0; --i)

edit: Ok, looking at it again the parent example is probably going to overflow or something right?

The other way around: size_t is an unsigned type, so decrementing 0 will wrap around to SIZE_MAX, a value that is positive as well as greater than 9. This means counter to your intuition, the first loop will terminate and the second one won't.

Yes (see other replies), and it's precisely the reason why this code shouldn't pass code review.

At first glance the first example looks like it should fail but in fact works. The second example I provided looks like it should work, but in fact loops infinitely.

The first one is tricky and nifty, but prone to bugs. Using signed counters is better way to go about it.