Subject: Regressing testing of system calls
To: None <tech-kern@netbsd.org>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-kern
Date: 06/14/1999 18:52:29
Folks,
I'm working on a small package to validate the accuracy of the
implementation of the NetBSD system call interface with that documented
in the manual pages - which is what led me to finding this oddity with
pipe(2). So far, I've only found one other problem - adjtime(2) didn't
return an error if the pointer "olddelta" wasn't valid and changed the
delta to the value pointed to by "delta" regardless. To do this testing,
I'm using the list of errors on the man page for each system call and
attempting to call them (with an appropriate environment) in such a way
that they do fail as described. Given some of the comments people have
made about what manual pages are meant to document, I'm pondering whether
or not this is the `correct' approach. Given the nature of pipe(2), I'm
sure there are situations where it might return an error relating to mbuf
shortage or similar. Does anyone have any better thoughts on the correct
way to approach this (if I'm going about it the wrong way) ? The aim here
is to built a package which can be used for regression testing of system
calls, where ensuring they return errors when they're supposed to is just
as important as them working (i.e. it's important that seteuid(0) doesn't
work if uid == ruid == euid == 65535).
Darren
p.s. I've done 19 system calls so far:
access, acct, adjtime, chdir, chflags, chmod, chown, close, dup, dup2,
fchflags, fchmod, fstat, gettimeofday, lchmod, lstat, open, pipe, state
- i.e. all `easy' ones ;-)