Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Jan 2008 17:28:40 -0500
From:      "Aryeh M. Friedman" <aryeh.friedman@gmail.com>
To:        Yar Tikhiy <yar@FreeBSD.org>
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
Message-ID:  <479BB418.2030808@gmail.com>
In-Reply-To: <200801261709.m0QH9f2D024309@repoman.freebsd.org>
References:  <200801261709.m0QH9f2D024309@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
-----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 <fts.h> 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-----




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?479BB418.2030808>