(find-maint.info)Design Issues

---

Next: Coding Conventions Prev: Maintaining GNU Programs Up: Top

---

Enter node , (file) or (file)node

3 Design Issues
***************

The findutils package is installed on many many systems, usually as a
fundamental component.  The programs in the package are often used in
order to successfully boot or fix the system.

   This fact means that for findutils we bear in mind considerations
that may not apply so much as for other packages.  For example, the fact
that findutils is often a base component motivates us to
   * Limit dependencies on libraries
   * Avoid dependencies on other large packages (for example,
     interpreters)
   * Be conservative when making changes to the 'stable' release branch

   All those considerations come before functionality.  Functional
enhancements are still made to findutils, but these are almost
exclusively introduced in the 'development' release branch, to allow
extensive testing and proving.

   Sometimes it is useful to have a priority list to provide guidance
when making design trade-offs.  For findutils, that priority list is:

  1. Correctness
  2. Standards compliance
  3. Security
  4. Backward compatibility
  5. Performance
  6. Functionality

   For example, we support the '-exec' action because POSIX compliance
requires this, even though there are security problems with it and we
would otherwise prefer people to use '-execdir'.  There are also cases
where some performance is sacrificed in the name of security.  For
example, the sanity checks that 'find' performs while traversing a
directory tree may slow it down.  We adopt functional changes, and
functional changes are allowed to make 'find' slower, but only if there
is no detectable impact on users who don't use the feature.

   Backward-incompatible changes do get made in order to comply with
standards (for example the behaviour of '-perm -...' changed in order to
comply with POSIX). However, they don't get made in order to provide
better ease of use; for example the semantics of '-size -2G' are almost
always unexpected by users, but we retain the current behaviour because
of backward compatibility and for its similarity to the block-rounding
behaviour of '-size -30'.  We might introduce a change which does not
have the unfortunate rounding behaviour, but we would choose another
syntax (for example '-size '<2G'') for this.

   In a general sense, we try to do test-driven development of the
findutils code; that is, we try to implement test cases for new features
and bug fixes before modifying the code to make the test pass.  Some
features of the code are tested well, but the test coverage for other
features is less good.  If you are about to modify the code for a
predicate and aren't sure about the test coverage, use 'grep' on the
test directories and measure the coverage with 'lcov' or another test
coverage tool.

   You should be able to use the 'coverage' Makefile target (it's
defined in 'maint.mk' to generate a test coverage report for findutils.
Due to limitations in 'lcov', this only works if your build directory is
the same asthe source directory (that is, you're not using a VPATH build
configuration).

   Lastly, we try not to depend on having a "working system".  The
findutils suite is used for diagnosis of problems, and this applies
especially to 'find'.  We should ensure that 'find' still works on
relatively broken systems, for example systems with damaged
'/etc/passwd' or '/etc/fstab' files.  Another interesting example is the
case where a system is a client of one or more unresponsive NFS servers.
On such a system, if you try to stat all mount points, your program will
hang indefinitely, waiting for the remote NFS server to respond.

   Another interesting but unusual case is broken NFS servers and
corrupt filesystems; sometimes they return 'impossible' file modes.
It's important that find does not entirely fail when encountering such a
file.