Re: size_t vs long.

[Paul Eggert <eggert@cs.ucla.edu>]

>> Second and more important, that code is bogus. Nobody should ever write code like that. If I wrote code like that, I'd *want* a trap.
> 
> for (size_t i = 41; i < sizeof A / sizeof A[0]; --i) {
>    A[i] = something_nice;
> }
> 
> The code above seems a bug by not being used to it.  Once you get used to it, it can become natural, but let's go for the more natural:
> 
> 
> for (size_t i = 0; i < sizeof A / sizeof A[0]; ++i) {
>    A[i] = something_nice;
> } 

Those loops do not mean the same thing. The first is bogus; the second 
one is OK (notice, the bogus loop has a "41", the OK loop doesn't).

I'm not surprised you didn't notice how bogus the first loop was - most 
people wouldn't notice it either. And it's Gustedt's main point! I don't 
know why he went off the rails with that overly-clever code, but he did.


> The main advantage of this code compared to the equivalent ssize_t or ptrdiff_t or idx_t code is that if you somehow write an off-by-one error, and manage to access the array at [-1], if i is unsigned you'll access [SIZE_MAX], which will definitely crash your program.

That's not true on the vast majority of today's platforms, which don't 
have subscript checking, and for which a[-1] is treated the same way 
a[SIZE_MAX] is. On my platform (Fedora 36 x86-64) the same machine code 
is generated for 'a' and 'b' for the following C code.

   #include <stdint.h>
   int a(int *p) { return p[-1]; }
   int b(int *p) { return p[SIZE_MAX]; }

Yes, debugging implementations might catch p[SIZE_MAX], but the ones 
that do will likely catch p[-1] as well.

In short, there's little advantage to using size_t for indexes, and 
there are real disadvantages due to comparison confusion and lack of 
signed integer overflow checking.


>> First, Gustedt technically incorrect, because the code *can* trap on 
>> platforms where SIZE_MAX <= INT_MAX,

> I honestly don't know of any existing platforms where that is true

They're a dying breed. The main problem from my point of view is that C 
and POSIX allow these oddballs, so if you want to write really portable 
code you have to worry about them - and this understadably discourages 
people from writing really portable code. (What's the point of coding to 
the standards if it's just a bunch of make-work?)

Anyway, one example is Unisys Clearpath C, in which INT_MAX and SIZE_MAX 
both equal 2**39 - 1. This is allowed by the current POSIX and C 
standards, and this compiler is still for sale and supported. (I doubt 
whether they'll port it to C23, so there's that....)


> C23 will require that signed integers are 2's complement, which I guess 
> removes the possibility of a trap

It doesn't remove the possibility, since signed integers can have trap 
representations. But we are straying from the more important point.