Re: [PATCH 3/6] tree-walk: use size_t consistently

> We store and manipulate the cumulative traverse_info.pathlen as an
> "int", which can overflow when we are fed ridiculously long pathnames
> (e.g., ones at the edge of 2GB or 4GB, even if the individual tree entry
> names are smaller than that). The results can be confusing, though
> after some prodding I was not able to use this integer overflow to cause
> an under-allocated buffer.
> 
> Let's consistently use size_t to generarate and store these, and make
> sure our addition doesn't overflow.