You have a typo:

sum += ptr[i];

really compiles into something that looks like:

sum += *(ptr + i);

(your post omitted the pointer dereference)

You’re assuming 0-indexing. The problem is that you can’t compare against any other value than zero when downcounting an unsigned int, therefore you must use a 1-indexed array. Or alternatively something ugly like this:

#define MSB_MASK_32 ( 1U << 31 )

BOOL is_overflow (uint32 i)
{
i = i & (1U < 0;
}

for(i=MAX-1; !is_overflow(i); i–)

I cannot quite see how this is a better alternative. These obfuscated examples are surely valid reasons to never write downcounting loops.

for(i=MAX; i!=0; i–)
{
sum += ptr[i];
}

Also, ptr[i] is so-called “syntatic sugar”. Behind the lines, the compiler will actually read that code as

sum += ptr + i;

——

As I sidenote, I’m against counting down myself. There is no doubt that down-counting loops are faster than up-counting ones on any known CPU.

Still, I don’t use them. In my opinion such optimizations should be handled by the compiler’s optimizer. When chosing between readability and efficiency, readability should win in 99% of the cases.

——

Regarding “Saks notation”, I’m sure he’s got plenty of good arguments about where to place the const keyword.

However, the C committee has stated that the feature of placing storage-class specifiers (extern, static etc) anywhere in the declaration will be removed from the language in the future. Thus int static x; will not be allowed in the future. So for consistency reasons, why not use the same notation for type qualifiers (const volatile etc)?

Then you don’t have to deal with pointer increment.

/Peter