From owner-cvs-all@FreeBSD.ORG Sat Jan 26 22:28:44 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD2CA16A46C for ; Sat, 26 Jan 2008 22:28:44 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.226]) by mx1.freebsd.org (Postfix) with ESMTP id 56B6713C45B for ; Sat, 26 Jan 2008 22:28:44 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so284080qbd.7 for ; Sat, 26 Jan 2008 14:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=Hd6nFvLEnsT/6W42Qt6H67Y574siyMUK6WFc34zamAE=; b=GZAT27hgrC6VnikjkqdPst3v9cECFW/CI1ef6wC0y6+8wN1oj8byisxxy4VQOZ9r1nSzFhZHcrT/SL+sh1RyHYwB8NNRw32Vst8HpimOJDF0WL+qIhG1Zb8fwsqP1CL6aJBCz9kA18jNcQiowP9QlvSfYebUuWlqWzUq8vDNxzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=WHUaDl9wH4ATfGpJmql6h0OvU+PZGdGxhZ91nQ3UHumUWS1GWdkA82m9D+5fayp8OrT225Mj8GxPNwMii5k9xHyB9Id4ZQd/CcBm+V0sVYfJgk1jMrUULM3ntDq6CijVWkdD8+ikBtbRUG8AsjxQMBAaB5n7S9T2PoXQl1fB7UI= Received: by 10.65.216.19 with SMTP id t19mr7705338qbq.95.1201386522787; Sat, 26 Jan 2008 14:28:42 -0800 (PST) Received: from flosoft.no-ip.biz ( [67.85.89.184]) by mx.google.com with ESMTPS id e11sm3221113qbc.5.2008.01.26.14.28.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Jan 2008 14:28:42 -0800 (PST) Message-ID: <479BB418.2030808@gmail.com> Date: Sat, 26 Jan 2008 17:28:40 -0500 From: "Aryeh M. Friedman" User-Agent: Thunderbird 2.0.0.9 (X11/20080121) MIME-Version: 1.0 To: Yar Tikhiy References: <200801261709.m0QH9f2D024309@repoman.freebsd.org> In-Reply-To: <200801261709.m0QH9f2D024309@repoman.freebsd.org> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src UPDATING src/include fts.h src/lib/libc/gen Makefile.inc Symbol.map fts-compat.c fts-compat.h fts.3 fts.c src/sys/sys param.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2008 22:28:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yar Tikhiy wrote: > yar 2008-01-26 17:09:41 UTC > > FreeBSD src repository > > Modified files: . UPDATING include > fts.h lib/libc/gen Makefile.inc Symbol.map fts-compat.c > fts-compat.h fts.3 fts.c sys/sys param.h Log: Our > fts(3) API, as inherited from 4.4BSD, suffers from integer fields > in FTS and FTSENT structs being too narrow. In addition, the > narrow types creep from there into fts.c. As a result, fts(3) > consumers, e.g., find(1) or rm(1), can't handle file trees an > ordinary user can create, which can have security implications. > > To fix the historic implementation of fts(3), OpenBSD and NetBSD > have already changed in somewhat incompatible ways, so we > are free to do so, too. This change is a superset of changes from > the other BSDs with a few more improvements. It doesn't touch > fts(3) functionality; it just extends integer types used by it to > match modern reality and the C standard. > > Here are its points: > > o For C object sizes, use size_t unless it's 100% certain that the > object will be really small. (Note that fts(3) can construct > pathnames _much_ longer than PATH_MAX for its consumers.) > > o Avoid the short types because on modern platforms using them > results in larger and slower code. Change shorts to ints as > follows: > > - For variables than count simple, limited things like states, use > plain vanilla `int' as it's the type of choice in C. > > - For a limited number of bit flags use `unsigned' because signed > bit-wise operations are implementation-defined, i.e., unportable, > in C. > > o For things that should be at least 64 bits wide, use long long > and not int64_t, as the latter is an optional type. See > FTSENT.fts_number aka FTS.fts_bignum. Extending fts_number `to > satisfy future needs' is pointless because there is fts_pointer, > which can be used to link to arbitrary data from an FTSENT. > However, there already are fts(3) consumers that require > fts_number, or fts_bignum, have at least 64 bits in it, so we must > allow for them. > > o For the tree depth, use `long'. This is a trade-off between > making this field too wide and allowing for 64-bit inode numbers > and/or chain-mounted filesystems. On the one hand, `long' is > almost enough for 32-bit filesystems on a 32-bit platform (our > ino_t is uint32_t now). On the other hand, platforms with a 64-bit > (or wider) `long' will be ready for 64-bit inode numbers, as well > as for several 32-bit filesystems mounted one under another. Note > that fts_level has to be signed because -1 is a magic value for it, > FTS_ROOTPARENTLEVEL. > > o For the `nlinks' local var in fts_build(), use `long'. The logic > in fts_build() requires that `nlinks' be signed, but our nlink_t > currently is uint16_t. Therefore let's make the signed var wide > enough to be able to represent 2^16-1 in pure C99, and even 2^32-1 > on a 64-bit platform. Perhaps the logic should be changed just to > use nlink_t, but it can be done later w/o breaking fts(3) ABI any > more because `nlinks' is just a local var. > > This commit also inludes supporting stuff for the fts change: > > o Preserve the old versions of fts(3) functions through libc symbol > versioning because the old versions appeared in all our former > releases. > > o Bump __FreeBSD_version just in case. There is a small chance > that some ill-written 3-rd party apps may fail to build or work > correctly if compiled after this change. > > o Update the fts(3) manpage accordingly. In particular, remove > references to fts_bignum, which was a FreeBSD-specific hack to work > around the too narrow types of FTSENT members. Now fts_number is > at least 64 bits wide (long long) and fts_bignum is an undocumented > alias for fts_number kept around for compatibility reasons. > According to Google Code Search, the only big consumers of > fts_bignum are in our own source tree, so they can be fixed easily > to use fts_number. > > o Mention the change in src/UPDATING. > > PR: bin/104458 Approved by: re (quite a while ago) > Discussed with: deischen (the symbol versioning part) Reviewed by: > -arch (mostly silence); das (generally OK, but we didn't agree on > some types used; assuming that no objections on -arch let me to > stick to my opinion) > > Revision Changes Path 1.517 +14 -0 src/UPDATING 1.12 > +11 -18 src/include/fts.h 1.131 +1 -1 > src/lib/libc/gen/Makefile.inc 1.8 +11 -8 > src/lib/libc/gen/Symbol.map 1.30 +28 -9 > src/lib/libc/gen/fts-compat.c 1.13 +0 -13 > src/lib/libc/gen/fts-compat.h 1.24 +6 -21 > src/lib/libc/gen/fts.3 1.29 +13 -41 src/lib/libc/gen/fts.c > 1.329 +1 -1 src/sys/sys/param.h > _______________________________________________ cvs-src@freebsd.org > mailing list http://lists.freebsd.org/mailman/listinfo/cvs-src To > unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" > This breaks the build for usr.sbin/setfmac/setfmac.c on -CURRENT (AMD64). Here is a very temp fix: cvs diff: Diffing . Index: setfmac.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/setfmac/setfmac.c,v retrieving revision 1.9 diff -r1.9 setfmac.c 158a159 > /* 161a163 > */ 163a166 > /* 166a170 > */ 172a177,178 > ; /* 174a181 > */ 175a183,184 > ; /* 178a188 > */ 440a451 > /* 443a455 > */ 485a498 > /* 487a501 > */ - -- Aryeh M. Friedman FloSoft Systems, Java Tool Developers Developer, not business, friendly http://www.flosoft-systems.com "Free software != Free beer" Blog: http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHm7QXQi2hk2LEXBARAgyKAJ4tzYrtAhUlYW84RopGL2Fu3Pm9iwCfYs+T bkzQ3M8fdqxHuFciiftb/uE= =30/Q -----END PGP SIGNATURE-----