Re: size_t best practice

On Sun, 18 Aug 2024 08:03:08 +0000
Mark Summerfield <mark@qtrac.eu> wrote:

Many C std. lib. functions accept and/or return size_t values esp. for
arrays incl. char* strings.
 
In view of this I'm using size_t throughout my code for array sizes
and indexes.
 
However, this means I have to be very careful never to decrement a
size_t of value 0, since, e.g., size_t size = 0; size--; results in
size == 18446744073709551615.
 
So I need to guard against this. Here is an example I'm using
(without the assert()s):
 
void vec_insert(vec* v, size_t index, void* value) {
    if (v->_size == v->_cap) {
        vec_grow(v);
    }
    for (size_t i = v->_size - 1; i >= index; --i) {
        v->_values[i + 1] = v->_values[i];
        if (!i) // if i == 0, --i will wrap!
            break;
    }
    v->_values[index] = value;
    v->_size++;
}
 
I've also noticed that quite a few array-related algorithms _assume_
that indexes are signed, so again I have to put in guards to avoid
subtracting below zero when I use size_t when implementing them.
 
So is it considered best practice to use int, long, long long, or
size_t, in situations like these?

My personal view is that in order to minimize a surprise factor one
should prefer signed array indices and signed loop control variables.
I.e. either int or ptrdiff_t.
I wouldn't use long or long long.
Some systems have ssize_t, but that's not part of standard C. Beyond, I
can't imagine a situation where ssize_t is better than ptrdiff_t.