svn commit: trunk/uClibc/libc/string/i386

Denys Vlasenko vda.linux at googlemail.com
Mon Jul 20 20:11:34 UTC 2009


Hi Mike,

On Monday 20 July 2009 14:25, Mike Frysinger wrote:
> On Friday 19 December 2008 08:51:39 vda at uclibc.org wrote:
> > Changeset:
> > Modified: trunk/uClibc/libc/string/i386/memchr.c
> >
> > +/* Uncomment TESTING, gcc -D__USE_GNU -m32 -Os memchr.c -o memchr
> > + * and run ./memchr
> > + */
> > +int main()
> > +{
> > +	static const char str[] = "abc.def";
> > +	printf((char*)memchr(str, '.',-2) - str == 3 ? "ok\n" : "BAD!\n");
> > +	printf((char*)memchr(str, '.',-1) - str == 3 ? "ok\n" : "BAD!\n");
> > +	printf((char*)memchr(str, '.', 0) == NULL    ? "ok\n" : "BAD!\n");
> > +	printf((char*)memchr(str, '.', 1) == NULL    ? "ok\n" : "BAD!\n");
> > +	printf((char*)memchr(str, '.', 2) == NULL    ? "ok\n" : "BAD!\n");
> > +	printf((char*)memchr(str, '.', 3) == NULL    ? "ok\n" : "BAD!\n");
> > +	printf((char*)memchr(str, '.', 4) - str == 3 ? "ok\n" : "BAD!\n");
> > +	printf((char*)memchr(str, '.', 5) - str == 3 ? "ok\n" : "BAD!\n");
> > +	printf((char*)memchr(str+3, '.', 0) == NULL    ? "ok\n" : "BAD!\n");
> > +	printf((char*)memchr(str+3, '.', 5) - str == 3 ? "ok\n" : "BAD!\n");
> > +}
> > +#endif
> 
> you've got to be kidding me.  we have test/string/ for a reason.  if you want 
> to make it easier to include on the fly, that's one thing, but the answer is 
> most certainly not "let's copy & paste a whole lot of code into the 
> implementation".

Well, it has one advantage over test/string: it can be built and run
just there. Imagine that you do some Obviously Correct (tm)
tweak in libc/string/i386/memchr.c.

Testing it using this code requires this: delete two //, copy
gcc command, save, paste gcc command, run the binary:

# gcc -D_GNU_SOURCE -m32 -Os memchr.c -o memchr
memchr.c: In function 'main':
memchr.c:64: warning: incompatible implicit declaration of built-in function 'printf'
# ./memchr
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok

Very fast.

Sure, "we must run testsuite anyway when we make chages".
But:
(a) we _still_ can run testsuite, right? It's not lost.
(b) running testsuite takes more time to set up.
It does not mean that we should not do it, it means
that in practice, we do it less.

It's a sad truth, but it's a truth nevertheless:
while most developers know thate testsuites are good,
yet many projects have incomplete, buggy, and/or slow
testsuites which are a chore to use, and therefore
they are not run as often as they should.

From this I conclude that one of the desirable things
in tests is how EASY and FAST you can run them.


These were reasons why I decided to save this testing code
when I was hacking on this file.

If you strongly feel that ugliness of having it there
outweighs the benefit of the possibility of running
such a test, feel free to remove.
--
vda


More information about the uClibc mailing list