Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Jun 2011 13:19:49 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: specification of cluts tests - code or/and data?

Luka, Rich -

On Mon, Jun 13, 2011 at 06:22:31AM +0400, Solar Designer wrote:
> Rather than write a piece of code for testing every property of every
> function, we could consider implementing interpreters or wrapper
> functions for common tests, or tables (arrays of structs) listing similar
> tests.  A problem here is that call to a string function via a function
> pointer might not invoke the same implementation that direct use would
> (there could be a macro or a C compiler builtin).  On the other hand,
> this also means that whatever approach to program structure we choose,
> we could want to test both kinds of uses of string functions (direct and
> via function pointer), to test both implementations (which might be
> present).

I wrote some code to illustrate this.  As written, it tests only some
trivial properties of a handful of string functions, but it is
extensible.  Please see attached.

Functions to test are specified like this:

static void *i_memcpy(void *dst, const void *src, size_t n)
{ return memcpy(dst, src, n); /* might use inlined code */ }

static fspec funcs[] = {
	{memcpy, {F_PTR | F_DST, F_DST, F_SRC, F_N}},
	{i_memcpy, {F_PTR | F_DST, F_DST, F_SRC, F_N}},
	{strcpy, {F_PTR | F_DST | F_NUL, F_DST, F_SRC}},
	{strncpy, {F_PTR | F_DST | F_PAD, F_DST, F_SRC, F_N}},
	{strcat, {F_PTR | F_DST | F_NUL, F_DST | F_SRC, F_SRC}},
	{strncat, {F_PTR | F_DST | F_NUL, F_DST | F_SRC, F_SRC, F_N}},
	{strchr, {F_PTR | F_IN_A1 | F_NUL, F_SRC, F_C}},
	{strstr, {F_PTR | F_IN_A1 | F_NUL, F_SRC, F_SRC}},
	{NULL}
};

As written, arg_next() tries to test all values in a range, but it will
need to be adjusted to skip ranges of string lengths for long strings.

As you can see, deeply nested loops seen in Luka's code are avoided
here.  Even with 8-char tabs (my preference), everything comfortably
fits in under 80 chars.

Alexander

View attachment "str.c" of type "text/plain" (3750 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.