find-maint: Design Issues

1 
1 3 Design Issues
1 ***************
1 
1 The findutils package is installed on many many systems, usually as a
1 fundamental component.  The programs in the package are often used in
1 order to successfully boot or fix the system.
1 
1    This fact means that for findutils we bear in mind considerations
1 that may not apply so much as for other packages.  For example, the fact
1 that findutils is often a base component motivates us to
1    * Limit dependencies on libraries
1    * Avoid dependencies on other large packages (for example,
1      interpreters)
1    * Be conservative when making changes to the 'stable' release branch
1 
1    All those considerations come before functionality.  Functional
1 enhancements are still made to findutils, but these are almost
1 exclusively introduced in the 'development' release branch, to allow
1 extensive testing and proving.
1 
1    Sometimes it is useful to have a priority list to provide guidance
1 when making design trade-offs.  For findutils, that priority list is:
1 
1   1. Correctness
1   2. Standards compliance
1   3. Security
1   4. Backward compatibility
1   5. Performance
1   6. Functionality
1 
1    For example, we support the '-exec' action because POSIX compliance
1 requires this, even though there are security problems with it and we
1 would otherwise prefer people to use '-execdir'.  There are also cases
1 where some performance is sacrificed in the name of security.  For
1 example, the sanity checks that 'find' performs while traversing a
1 directory tree may slow it down.  We adopt functional changes, and
1 functional changes are allowed to make 'find' slower, but only if there
1 is no detectable impact on users who don't use the feature.
1 
1    Backward-incompatible changes do get made in order to comply with
1 standards (for example the behaviour of '-perm -...' changed in order to
1 comply with POSIX). However, they don't get made in order to provide
1 better ease of use; for example the semantics of '-size -2G' are almost
1 always unexpected by users, but we retain the current behaviour because
1 of backward compatibility and for its similarity to the block-rounding
1 behaviour of '-size -30'.  We might introduce a change which does not
1 have the unfortunate rounding behaviour, but we would choose another
1 syntax (for example '-size '<2G'') for this.
1 
1    In a general sense, we try to do test-driven development of the
1 findutils code; that is, we try to implement test cases for new features
1 and bug fixes before modifying the code to make the test pass.  Some
1 features of the code are tested well, but the test coverage for other
1 features is less good.  If you are about to modify the code for a
1 predicate and aren't sure about the test coverage, use 'grep' on the
1 test directories and measure the coverage with 'lcov' or another test
1 coverage tool.
1 
1    You should be able to use the 'coverage' Makefile target (it's
1 defined in 'maint.mk' to generate a test coverage report for findutils.
1 Due to limitations in 'lcov', this only works if your build directory is
1 the same asthe source directory (that is, you're not using a VPATH build
1 configuration).
1 
1    Lastly, we try not to depend on having a "working system".  The
1 findutils suite is used for diagnosis of problems, and this applies
1 especially to 'find'.  We should ensure that 'find' still works on
1 relatively broken systems, for example systems with damaged
1 '/etc/passwd' or '/etc/fstab' files.  Another interesting example is the
1 case where a system is a client of one or more unresponsive NFS servers.
1 On such a system, if you try to stat all mount points, your program will
1 hang indefinitely, waiting for the remote NFS server to respond.
1 
1    Another interesting but unusual case is broken NFS servers and
1 corrupt filesystems; sometimes they return 'impossible' file modes.
1 It's important that find does not entirely fail when encountering such a
1 file.
1