bin/104458: fts(3) can't handle very deep trees

[Yar Tikhiy]

The following reply was made to PR bin/104458; it has been noted by GNATS.

From: Yar Tikhiy <yar at comp.chem.msu.su>
To: bug-followup at FreeBSD.org
Cc:  
Subject: Re: bin/104458: fts(3) can't handle very deep trees
Date: Sun, 29 Oct 2006 14:13:48 +0300

 JFTR:
 
 NetBSD has the fts_*pathlen fields in FTSENT extended to u_int.
 But why not to size_t?
 
 NetBSD's fts_level is still short though.  If we extend ours, it
 should be int64_t as we don't want to hit INT_MAX right after SHRT_MAX.
 
 BTW, FTW.level is int now, as is FTW.base.  The former should be
 the same as FTS.fts_level while the latter begs to be size_t as
 it's an array index.  SUSv3 defines them as int though.
 
 In addition, NetBSD folks've made fts_number 64-bit.  Perhaps we
 could just make our fts_bignum and fts_number the same field if can
 take the ABI breakage.
 
 Other candidates for extension to size_t are fts_pathlen and
 fts_nitems in FTS as they both are essentially array indexes.
 
 Lastly, the flag fields in FTS could be extended, too, because one
 of them, fts_info, has 15 bits used now.
 
 After changing fts.h, fts.c should be made 64-bit clear.
 
 -- 
 Yar