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

Re: [csmith-dev] exceptions

Thanks for your suggestion. side-effecting expressions, such as comma
operator, is on my todo list. Making comma a macro is a good idea. 

Generating try/catch/throw statements are not hard, the difficult part is
how to add them without disrupting the current dataflow analysis. Luckily
the analyzer handles goto statements already. A throw statement is
essentially a jump statement. It's actually easier to support than "goto"
because it always creates forward edges that don't require fix-point
searching for dataflow analysis. It requires some work to determine the
destination at generation time, but not too much. 

> -----Original Message-----
> From: csmith-dev-bounces@flux.utah.edu
> [mailto:csmith-dev-bounces@flux.utah.edu] On Behalf Of Arthur O'Dwyer
> Sent: Saturday, April 30, 2011 8:55 PM
> To: csmith-dev@flux.utah.edu
> Subject: Re: [csmith-dev] exceptions
> Since you asked publicly, I'll offer my half-formed thoughts on the
matter. ;)
> Ideally, an exception-handling test would include use of (throw x) as
> a subexpression, e.g. "if (g_42 || (throw "hi" , 0)) { ... }", since
> I'm sure there are numerous bugs waiting to be found in that area.
> Off the top of my head, I can't think of any way to use (throw x) as a
> subexpression without also using a comma operator.[1]
> Ideally, an exception-handling test would also include throwing and
> catching arbitrary types, and the catch clauses would include
> catch-by-reference and catch-by-value --- and ideally some of those
> catch clauses would actually be entered! --- but that all seems pretty
> hard (he says, without really knowing anything about Csmith).
> Just sprinkling in "try { random_code; } catch (...) { random_code; }"
> (that's a literal "...", not a metasymbol ;)) would be trivial, and I
> bet it would find a handful of bugs just on its own, but you wouldn't
> get to do anything really interesting, like testing that the right
> catch-handler was entered or that the value thrown was the same as the
> value caught.  As long as your main() is completely enclosed in a
> try-block with a "catch (...)" handler (and if you don't let any
> global ctors/dtors throw exceptions), that would be pretty much
> foolproof, albeit ridiculously conservative.
> [1] - Digression: If you do end up autogenerating comma operators, may
> I suggest using "#define COMMA ," and then "(a COMMA b)", to avoid
> confusion with the function-argument-separator comma?  I've dealt with
> autogenerated code that used just an extra space "(a , b)" to indicate
> the operator, and that wasn't too bad, but in hindsight I bet we could
> have done better.
> -Arthur
> On Sat, Apr 30, 2011 at 3:03 PM, John Regehr <regehr@cs.utah.edu> wrote:
> > This is a question for Xuejun, but I thought I'd ask it publicly.
> >
> > How hard would it be to add exceptions to Csmith's output?  I assume
> > could be handled simply by adding a control flow edge from every throw
> > every catch that it might possibly reach.
> >
> > I realize we do not currently focus on C++, but if we're going to add a
> > single feature that would stress-test C++ implementations in a useful
> > this might be the one to add.  In contrast, adding meaningful use of
> > sounds difficult.