From owner-freebsd-bugs@FreeBSD.ORG Sun Oct 29 11:20:24 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E879A16A403 for ; Sun, 29 Oct 2006 11:20:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7D4143D45 for ; Sun, 29 Oct 2006 11:20:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k9TBKOJv057365 for ; Sun, 29 Oct 2006 11:20:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k9TBKOaL057364; Sun, 29 Oct 2006 11:20:24 GMT (envelope-from gnats) Date: Sun, 29 Oct 2006 11:20:24 GMT Message-Id: <200610291120.k9TBKOaL057364@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Yar Tikhiy Cc: Subject: Re: bin/104458: fts(3) can't handle very deep trees X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yar Tikhiy List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2006 11:20:25 -0000 The following reply was made to PR bin/104458; it has been noted by GNATS. From: Yar Tikhiy 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