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

Re: [creduce-dev] Avoiding syntax warnings and errors

Hi Vegard, I'll agree with Yang that the point of C-Reduce is basically to *not* worry about any of the things you mention, deferring those problems to the interestingness test.

I typically include some tests for warnings in the interestingness test, or else just manually fix up the warnings at the end, once reduction finishes. If the final output is less than a couple hundred bytes, this is usually easy.

Those things said, you can probably disable some of the problematic passes, but I don't think any of us has ever tried to do that.

Regarding try-catch, yes, we'd like to have a pass for that. I added a note about this to our TODO list, but mostly we're too busy for adding new stuff these days.


On 3/14/18 12:47 AM, Yang Chen wrote:
Hi Vegard,

On 03/13/2018 12:08 PM, Vegard Nossum wrote:

First of all, thanks for C-reduce! It's extremely useful and valuable.

I am trying to run C-reduce on a large number of (large-ish,
preprocessed) source files and I have run into the following problems
and/or minor annoyances:

Especially for sources that crash the compiler, programs often come
out with syntax errors and warnings, even though the syntax was fine
in the original program. One mitigation I have found that helps to a
certain degree is to test that the number of braces ("(", ")", "[",
"]", "{", "}", "<", ">") match up in the acceptance script, but this
breaks down if those characters are present and/or unbalanced, say, in
source comments or string literals.

There are other syntax errors which are introduced as well, for
example the removal of semicolons and return values (and return
statements). A mitigation for this is to count the number of warnings
in the original file, pass it to the acceptance script through, say,
an environment variable, and make sure that number never increases.
There are drawbacks, though: if there are any warnings to start with,
these could disappear and new ones be introduced (i.e. there is no
easy way to force this number to always go down). It also slows down
the whole reduction process by a ridiculous amount, going from maybe 1
minute to over 10 for the initial passes alone.

Another mitigation is of course passing -Werror to have those warnings
turned into errors, but again that only works if the original source
does not have those warnings to start with.

My final script uses a combination of brace counting, -Werror=
options, and stderr grepping, but it's far from perfect and it's
actually a huge slowdown compared to just using a dumb script and then
fixing up the resulting test case by hand (i.e. adding "void" or "int"
where the return type is missing, adding "return 0;" statements to the
end of functions, etc.).

I am not sure, but it seems like there might be a small number of
passes responsible for introducing the worst of these syntax errors.

Any hints, tips, or ideas for how to improve the situation? Could it
be possible to provide a command-line switch that will skip passes
that remove "too much"?

C-Reduce doesn't have a mode where it could only produce syntactically correct outputs or work towards producing less invalid outputs. There are quite a few passes that can introduce syntax-related errors. At the moment, I couldn't think of a better way to avoid that except massaging the script as you did.  Sorry for the inconvenience.

Another thing I noticed is that C-reduce often leaves superfluous
try...catch statements. I've often found the final output to contain a
try...catch that could simply be substituted by either just the
try-block, just the catch-block(s), just the catch-declaration(s), or
the concatenation of a combination of them (without the "try" and
"catch" themselves obviously).

Yes, this is a known issue. Currently, C-reduce doesn't have a specific pass for processing try/catch statements.

- Yang