Re: [PATCH] grep: -r no follows symlinks

[Paul Eggert]

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.