For me, the more general question is how to best deal with the increasing
number of options that we and other people want. I think that this requires
some thinking, before the options get completely out of hand.
Eric, you probably mean both, but two concerns here are
the user interface and the cleanliness of the implementation.
- for the user interface, I can assure you as a user
that Csmith is extremely easy to use and that it would remain
so even in the worst case, with a couple
more options grafted on Frankenstein-style.
Each option has a clear effect, orthogonal to that of the other
options, and the defaults are very well chosen. Wanting
unsafe programs is the unusual case, so the default for
the new options would be off. In fact, this new use is unusual
enough to go in the -hh category in my humble opinion.
- for the implementation, it is not appropriate for me to say
anything, but I'll do anyway.
Sometimes new, unplanned features turn out well. Years ago,
John asked about signed overflows in Frama-C's value analysis
(the value analysis assumed 2's complement for signed overflows).
His arguments were convincing as always, so I just had to do it.
While the implementation of this feature is recognizably bolted on,
it only takes a few lines in a single place. The implementation
of this feature is probably shorter than if it had been
planned from the start: who knows in what horrible ways
I would have over-engineered this one given the chance!
And it turned out to capture INT_MIN / (-1) (which produces
2's complement results on some processors
but fails on IA32/amd64) at the same time as INT_MAX + 1.
"Go with the flow" would be my unsolicited, very self-interested
recommendation. A random generator of interesting unsafe
programs would be a world-changing new tool.
Pascal