Re: Possible oversight in setvbuf()

[Rich Felker <dalias@libc.org>]

On Fri, Jul 13, 2018 at 06:19:30PM -0400, Christopher Friedt wrote:
> On Fri, Jul 13, 2018, 6:06 PM Rich Felker, <dalias@libc.org> wrote:
> 
> > On Fri, Jul 13, 2018 at 05:46:54PM -0400, Christopher Friedt wrote:
> > > A good process for adding new features is to add tests with them. Even if
> > > there is only a test for expected behaviour, at least it will catch one
> > > possible regression.
> >
> > Yes, I should really do that more. Sometimes it's not obvious what
> > should be tested though. In the case of setvbuf, the intended behavior
> > is in some sense untestable (the previous implementation not using the
> > caller-provided buffer was valid); in hindsight the obvious important
> > thing to test is that it doesn't result in writes outside the buffer.
> >
> 
> If you need more than that basic test.c program that I provided before for
> addrconfig, i'd be happy to add some more test cases.

The hard thing about testing that functionality is that it's dependent
on environmental factors (network interface configuration). The same
problem also applies to the rest of the resolver functionality, where
you'd want to be able to hook it up to a known, and possibly
malicious, nameserver that's part of the test harness.

There are two "obvious" choices for how to achieve this:

1. Using Linux namespaces (and assuming user namespace functionality
   is available to access them, which requires either appropriate
   configuration or root) so that control over the filesystem and
   network interfaces is available. Or,

2. Implementing a tracer (perhaps just seccomp) process that catches
   and rewrites the syscall results to simulate the conditions we want
   to test.

Neither is particularly portable outside of Linux (note that libc-test
is OS- and libc-agnostic). Option 1 is cleaner and simpler and more
flexible, but won't work on all systems (and especially not on more
hardened ones). I'm not sure if Szabolcs Nagy (libc-test maintainer)
likes either idea.

Rich