On Tue, Nov 24, 2020 at 12:21:36PM +0300, Alexey Izbyshev wrote:
> On 2020-11-24 09:30, Rich Felker wrote:
> >I think before this goes upstream we should have a good set of
> >testcases that can be contributed to libc-test. Do you have ideas for
> >coverage? Some that come to mind:
> >
> Added some more ideas.
> 
> >- Absolute argument starting with /, //, and ///
> - Absolute argument equal to one of /, //, and ///
> >- Absolute symlink target starting with /, //, and ///
> - Absolute symlink target equal to one of /, //, and ///, with the
> link separated from the following component with /, //
> >- Final / after symlink-to-dir, dir, symlink-to-nondir, nondir
> - Intermediate / after symlink-to-nondir, nondir
> >- Final / in link contents after [the above]
> - Multiple / after ., .., normal component
> >- Initial .. in argument, cwd root or non-root
> >- Initial .. in symlink target, symlink in root or non-root
> >- Initial ...
> >- .. following symlink-to-dir, dir, symlink-to-nondir, nondir
> - . following symlink-to-dir, dir, symlink-to-nondir, nondir
> >- More .. than path depth
> >- Null argument
> >- Empty string argument
> - Argument consisting of a single ., ..
> >- Empty string link contents (testable only with seccomp hack)
> >- Argument valid abs path exact length PATH_MAX-1
> >- Argument valid rel path exact length PATH_MAX-1 to short abs path
> - Argument with PATH_MAX length (ENAMETOOLONG)
> - A relative symlink in the argument such that the length of the
> result is PATH_MAX-1 (valid path), PATH_MAX (ENAMETOOLONG)
> - An absolute symlink in the argument similar to the above
> - A relative argument with the current directory similar to the above
> - An argument consisting of a single (relative, absolute) symlink
> with the target having length PATH_MAX-1
> - An argument ending with a relative symlink with the target having
> length PATH_MAX-1 (ENAMETOOLONG)
> - An argument ending with an absolute symlink with the target having
> length PATH_MAX-1 (valid path)

OK, here are my WIP testcases. They only cover static cases, not
anything that depends on implementation-defined value of PATH_MAX or
how the working directory combines with tests to reach PATH_MAX.

The way you run the tests is by running ../setup.sh then ../checker.sh
from a scratch subdir of the dir containing the test files (realpath.c
also needs to be compiled and linked against the realpath impl you
want to test)

Format of the testcase file is one test per line, input and expected
output separated by whitespace. . and .. in expected output are
translated based on working dir. Error names are treated as output
since they don't fall in same namespace (no initial /).

All tests are currently passing for me.

If you have ideas for additional static tests that fit the form and
are easy to add, please suggest.

Rich