Type for array index in C99

Question

What type for array index in C99 should be used? It have to work on LP32, ILP32, ILP64, LP64, LLP64 and more. It doesn't have to be a C89 type.

There are 5 candidates:

• size_t
• ptrdiff_t
• intptr_t / uintptr_t
• int_fast*_t / uint_fast*_t
• int_least*_t / uint_least*_t

There is simple code to better illustrate problem. What is the best type for i and j in these two particular loops. If there is a good reason, two different types are fine too.

for (i=0;i<imax;i++) {
        do_something(a[i]);
}
/* imin can be less than 0 */
for (j=jmin;j<jmax;j++) {
        do_something(a[j]);
}

P.S. In the first version of question I had forgotten about negative indexes.

P.P.S. I am not going to write a C99 compiler. However any answer from a compiler programmer would be very valuable for me.

Possible duplicates:

• http://stackoverflow.com/questions/1464174/size-t-vs-intptr-t

Answer 1

Since the type of sizeof(array) (and malloc's argument) is size_t, and the array can't hold more elements than its size, it follows that size_t can be used for the array's index.

EDIT This analysis is for 0-based arrays, which is the common case. ptrdiff_t will work in any case, but it's a little strange for an index variable to have a pointer-difference type.

Answer 2

I think you should use ptrdiff_t for the following reasons

• Indices can be negative (thus all unsigned types, including size_t, are out of question)
• The type of p2 - p1 is ptrdiff_t. The type of i in the reverse thing, *(p1 + i), should be that type too (notice that *(p + i) is equivalent to p[i])

Answer 3

If you know the maximum length of your array in advance you can use

• int_fast*_t / uint_fast*_t
• int_least*_t / uint_least*_t

In all other cases i would recommend using

• size_t

or

• ptrdiff_t

depending on weather you want to allow negative indexes.

Using

• intptr_t / uintptr_t

would be also safe, but have a bit different semantics.

Answer 4

I almost always use size_t for array indices/loop counters. Sure there are some special instances where you may want signed offsets, but in general using a signed type has a lot of problems:

The biggest risk is that if you're passed a huge size/offset by a caller treating things as unsigned (or if you read it from a wrongly-trusted file), you may interpret it as a negative number and fail to catch that it's out of bounds. For instance if (offset<size) array[offset]=foo; else error(); will write somewhere it shouldn't.

Another problem is the possibility of undefined behavior with signed integer overflow. Whether you use unsigned or signed arithmetic, there are overflow issues to be aware of and check for, but personally I find the unsigned behavior a lot easier to deal with.

Yet another reason to use unsigned arithmetic (in general) - sometimes I'm using indices as offsets into a bit array and I want to use %8 and /8 or %32 and /32. With signed types, these will be actual division operations. With unsigned, the expected bitwise-and/bitshift operations can be generated.