Re: size_t vs long.

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

On 2022-11-17 01:21, Alejandro Colomar via Libc-alpha wrote:

> I'd like to change your opinion.  Please read this excellent article by 
> Jens Gustedt (member of WG14, the group that develops the ISO C 
> standard) which explains why size_t is better:
> 
> <https://gustedt.wordpress.com/2013/07/15/a-praise-of-size_t-and-other-unsigned-types/>

Sorry, but that article is not excellent: it's mostly wrong. Among other 
things it says size_t is better because it lets you write code like this:

> for (size_t i = 41; i < sizeof A / sizeof A[0]; --i) {
>    A[i] = something_nice;
> }

and that there will be "No traps, no signals, no exceptions".

First, Gustedt technically incorrect, because the code *can* trap on 
platforms where SIZE_MAX <= INT_MAX, because on such a platform when i 
is zero, '--i' can store a trap value into i.

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. Traps are 
*good* when they prevent buggy code from doing further damage.

For what it's worth, in Gnulib's more recent code we've been using the 
type "idx_t". It is a signed type, thus avoiding C's bug-inducing 
comparison rules, where most size_t values compare to be less than -1.
However, by convention idx_t contains only nonnegative values.

The idx_t type is *much* better than size_t, both because we can tell 
the compiler to do some overflow checking on it, and because it compares 
nicely to ordinary integers. This overcomes two major disadvantages of 
size_t.