Date: Sun, 29 Oct 2006 11:20:24 GMT From: Yar Tikhiy <yar@comp.chem.msu.su> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/104458: fts(3) can't handle very deep trees Message-ID: <200610291120.k9TBKOaL057364@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/104458; it has been noted by GNATS. From: Yar Tikhiy <yar@comp.chem.msu.su> To: bug-followup@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610291120.k9TBKOaL057364>