- cmutate has the problem that mutants are generated on a line-by-line basis. cmutate has no abstracted understanding of the C semantic. Which results in uncompilable mutants. I think that this approach will have a larger problem with test cases generated by csmith, since they have some really compilated pointer reference semantic there (as far as i can tell)
This might not be a problem, though, since it's easy to automatically discard non-compilable mutants, as long as you eventually get some that compile.
Since John suggested reusing the creduce infrastructe, how do creduce and csmith relate to one another? Are there shared sources or concepts?
They're not directly related. I wrote C-Reduce because Csmith was finding a lot of compiler bugs and the existing testcase reduction tool, delta, gets stuck at unacceptably large local minima.
C-Reduce has a library of program transformations including some quite high-level ones, under the clang-delta umbrella. You'll just have to dig in any see if any of it suits your needs.
Another idea that came to my mind was to manipulate the random stream csmith uses to generate files. As I understand it correctly, csmith uses lrand48() to generate a sequence of random numbers that are used to construct the testcase. If filled with the same seed, the same testcase would be build. What would happen, if I drop/replace one of these numbers when generated the "mutant"? For example, one number that is used relative late in the generation process:
Since you said "relatively late" I think you have already grasped the problem, which is that Csmith is a stateful generator and you can't just swap out a decision since many decisions affect all subsequent decisions.
But since the hack you describe is extremely easy you might as well try this out and see what happens, no big loss if it doesn't work.
John