[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [csmith-dev] Generate two slightly different files

- 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.