C-Vise is a super-parallel Python port of the C-Reduce. The port is fully compatible to the C-Reduce and uses the same efficient LLVM-based C/C++ reduction tool named clang_delta.
I’ve been using this for years. Really excellent. In a few minutes it can cut down thousands of lines of code that has a problem to just 5 or 10 or 20 lines that has the same problem.
The tool doesn’t have anything but the most superficial knowledge of C – mostly the structure imposed by {} and (). It works with other similar languages such as Java, JavaScript, C#. The biggest requirement is that you be able to put all definitions the compiler will see into a single source file. That’s easy in C/C++ as you just do a pre-processor only pass using gcc or clang. Ironically this is tougher in languages with more sophisticated “import” statements.
cvise and C-Reduce both use libclang to improve their reduction, so they do have a fair amount of knowledge about C and C++. delta, on the other hand, I think indeed only knows that sort of basic primitive structure.
C-Reduce is a tool that takes a large C or C++ program that has a property of interest (such as triggering a compiler bug) and automatically produces a much smaller C/C++ program that has the same property. It is intended for use by people who discover and report bugs in compilers and other tools that process C/C++ code.
Not sure how the antithesis angle would work, but (https://github.com/DRMacIver/shrinkray) is David MacIver’s parallel format agnostic reducer. I believe it actually just uses C-reduce/Csmith for C-like source code (but you should probably double check it, I’m not 100% sure).
Unit tests should be automatically generated as part of compilation step. The generated tests should be versioned together with the source, so that when executed the results of their current version vs prev-version can be diffed, and only the differences that were not expected to be different (eg pre-version function has not changed) should be flagged for manual review.
Blackbox tests should be either hand written, or generated from a replay log.
Both types of tests have the place in SDLC, but writing unit-tests by hand seems like a problem begging to be automated away.
There is also https://github.com/marxin/cvise/:
Seems to be faster than the original one.
I’ve been using this for years. Really excellent. In a few minutes it can cut down thousands of lines of code that has a problem to just 5 or 10 or 20 lines that has the same problem.
The tool doesn’t have anything but the most superficial knowledge of C – mostly the structure imposed by {} and (). It works with other similar languages such as Java, JavaScript, C#. The biggest requirement is that you be able to put all definitions the compiler will see into a single source file. That’s easy in C/C++ as you just do a pre-processor only pass using gcc or clang. Ironically this is tougher in languages with more sophisticated “import” statements.
cvise and C-Reduce both use libclang to improve their reduction, so they do have a fair amount of knowledge about C and C++. delta, on the other hand, I think indeed only knows that sort of basic primitive structure.
The documentation page has disappeared, but here’s the latest archived version.
A blog post on The Design And Evolution of C-reduce is also interesting.
I wonder if a multi-process version of this this can be built on top of https://antithesis.com/ ?
I’d guess it is extremely specific to C/C++, so it would be hard to make it work for a Go + C combo
But something that can reduce
c-program1 | c-program2 | c-program3would be very interestingNot sure how the antithesis angle would work, but (https://github.com/DRMacIver/shrinkray) is David MacIver’s parallel format agnostic reducer. I believe it actually just uses C-reduce/Csmith for C-like source code (but you should probably double check it, I’m not 100% sure).
I agree with the sentiment.
My general view:
Unit tests should be automatically generated as part of compilation step. The generated tests should be versioned together with the source, so that when executed the results of their current version vs prev-version can be diffed, and only the differences that were not expected to be different (eg pre-version function has not changed) should be flagged for manual review.
Blackbox tests should be either hand written, or generated from a replay log.
Both types of tests have the place in SDLC, but writing unit-tests by hand seems like a problem begging to be automated away.
Hm I think that is a different idea … I’m thinking of “ddmin” for multi-process programs, where each program has a different piece of source code
https://www.debuggingbook.org/html/DeltaDebugger.html
Not sure it exists at all or is possible, but it would be useful IMO
[Comment removed by author]