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

[Yar Tikhiy]

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