Commit Graph

14 Commits

Author SHA1 Message Date
Ed Schouten
6ed0f50f78 Allow certain headers to be included more easily.
Spotted by:	http://hacks.owlfolio.org/header-survey/
2013-05-21 21:20:10 +00:00
Warner Losh
f2556687c6 Remove the Berkeley clause 3's.
Add a few $FreeBSD$
2010-02-16 19:39:50 +00:00
Yaroslav Tykhiy
48aaad5fbc 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)
2008-01-26 17:09:40 +00:00
Pawel Jakub Dawidek
28644c1bbb Introduce new field 'fts_bignum' which is 64bit long and will allow to
make utilities like du(1) 64bit-clean.
When this field is used, one cannot use 'fts_number' and 'fts_pointer'
fields.

This commit doesn't break API nor ABI.

This work is part of the BigDisk project:

	http://www.FreeBSD.org/projects/bigdisk/

Discussed on:	arch@
MFC after:	5 days
2005-01-07 00:06:20 +00:00
Peter Edwards
07dee1a777 Fix some^Wseveral style bugs from last commit.
Remove "sys/types.h" as "sys/param.h" is already included

Use cast rather than back-pointer to convert from public to private
version of FTS data, and so avoid littering fts.h with any of the
details.

Pointed out By: bde, kientzle
2004-05-12 21:38:39 +00:00
Bruce Evans
d98d9ce623 Fixed style bugs in previous commit (bogus forward declaration and
inconsistent capitalization in comments).
2004-05-10 09:36:26 +00:00
Peter Edwards
99ca5b8804 The FTS_NOSTAT option is an optimisation that reduces the number
of stat(2) calls by keeping an eye of the number of links a directory
has. It assumes that each subdirectory will have a hard link to its
parent, to represent the ".." node, and stops calling stat(2) when
all links are accounted for in a given directory.

This assumption is really only valid for UNIX-like filesystems: A
concrete example is NTFS. The NTFS "i-node" does contain a link
count, but most/all directories have a link count between 0 and 2
inclusive. The end result is that find on an NTFS volume won't
actually traverse the entire hierarchy of the directories passed
to it. (Those with a link count of two are not traversed at all)

The fix checks the "UFSness" of the filesystem before enabling the
optimisation.

Reviewed By: Tim Kientzle (kientzle@)
2004-05-08 15:09:02 +00:00
Garrett Wollman
0d3bcc2e80 Make the threatened fts(3) ABI fix. FTSENT now avoids the use of the struct
hack, thereby allowing future extensions to the structure (e.g., for extended
attributes) without rebreaking the ABI.  FTSENT now contains a pointer to the
parent stream, which fts_compar() can then take advantage of, avoiding the
undefined behavior previously warned about.  As a consequence of this change,
the prototype of the comparison function passed to fts_open() has changed
to reflect the required amount of constness for its use.  All callers in the
tree are updated to use the correct prototype.

Comparison functions can now make use of the new parent pointer to access
the new stream-specific private data pointer, which is intended to assist
creation of reentrant library routines which use fts(3) internally.

Not objected to in spirit by: -arch
2002-09-21 01:28:41 +00:00
Bruce Evans
514a0ae7d2 Fixed some style bugs in the removal of __P(()). Some function parameter
lists were outdented to column 0.
2002-03-26 01:35:05 +00:00
Warner Losh
bb28f3c29b Breath deep and take __P out of the system include files.
# This appears to not break X11, but I'm having problems compiling the
# glide part of the server with or without this patch, so I can't tell
# for sure.
2002-03-23 17:24:55 +00:00
Ruslan Ermilov
589ee357a4 Complete prototype for fts_compar. 2001-06-13 14:59:57 +00:00
Eivind Eklund
f756433e8b Back out all of yesterdays include file changes. 1997-05-07 20:01:10 +00:00
Eivind Eklund
48ea0bec18 Make a lot of include-files self-contained. I excluded the patches changing
int's to gid_t and uid_t - should I commit these, too?

Closes PR misc/2625.

Submitted by:	Julian Assange <proff@iq.org>
1997-05-07 02:27:18 +00:00
Peter Wemm
dee7a427ff Import CSRG 4.4BSD-Lite2 includes onto vendor branch 1997-03-11 11:11:37 +00:00