Re: [csmith-dev] exceptions

["Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>]

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 this
> could be handled simply by adding a control flow edge from every throw to
> 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 way,
> this might be the one to add.  In contrast, adding meaningful use of classes
> sounds difficult.