On 03/10/2012 02:19 PM, Jim Meyering wrote: > I see legacy types like the latter "int" that should be bool, > but that can obviously wait.
My sentiments exactly. > I'd use an unsigned type, since it will never be negative. I've changed it to 'size_t' in my private copy, but I can't resist telling you my reasoning. The value in question is always either 0 or 2. So, 'int' is wrong (because it allows bogus negative values); but 'unsigned' is equally wrong (because it allows values greater than INT_MAX, which is the same number of bogus values). If it's a question of disallowing bogus values, then (other things being equal) signed is better than unsigned, since some debugging C implementations diagnose signed overflow, whereas C implementations are not allowed to diagnose unsigned overflow. Furthermore, C compilers can sometimes generate better code for signed arithmetic than unsigned, precisely because overflow has undefined behavior so this gives them more freedom to optimize. Finally, signed arithmetic is closer to what naive programmers expect. It is true that using size_t allows carefully-written code to access arrays whose sizes are in the range PTRDIFF_MAX+1 .. SIZE_MAX bytes, and this is an advantage of using size_t. However, most code is not that carefully-written -- including most GNU code, I expect -- because pointer subtraction does not work with such arrays, and in applications this disadvantage often outweighs any advantage of supporting such large arrays. So, when either a signed or an unsigned value will work, it's typically better to use signed.
