Hey Alexander. Cluts doesn't test negative values for memcpy. Such a thing hasn't occured to me: The prototype for the function specifies a size_t argument, and size_t is supposed to be unsigned. This means, _afaik_, that a negative value should be implicitly cast to a positive "equivalent". So, I assume testing for this would be only useful as a way to show that (one of) eglibc's implementation(s) doesn't obey sheer basics. However (not that this isn't an eerie bug), I'm also a bit skeptical as to how a user-provided value [+not stored in a size_t] would find itself in an argument to memcpy.
String.c is next after the alloc.c rewrite which is what I'm doing now (and possibly after the task #7 which you suggested a while back), so if Rich thinks this may be important to test for a reason unobvious to me, I guess I can throw it in (though I'd have to use some non-size_t, sufficiently big signed type to store test data :-/). In case of eglibc, I could have memcpy jump to the same function used as the signal handler, and then it'd jump back to a setjmp and we'd notice this behavior (that is, assuming the size of the real argument type can be callculated for each platform). If I then use the same setjmp/handler for a SIGSEGV, we could also catch other hypothetical and only similarily buggy implementation behavior, and have both report a same ambigous "negative argument" error message. But then I guess the same applies to all other functions that should take a size_t or any other positive type, doesn't it? :-/
Luka.