Hi Tzafrir,C-Reduce's termination condition is that running all passes fails to reduce the size of the input, so this issue isn't going to prevent C-Reduce from terminating normally. It won't get into an infinite loop or anything. If you let C-Reduce terminate does it end up giving you an output that is acceptable?
On the other hand, if this really bothers you, it shouldn't be too hard to find the responsible pass(es) and leave them out of the pass schedule. If you like, I could add a "--remove-pass" command line option that avoids the need to edit creduce.in to drop passes.
The problem you are running into seems uncommon enough that I don't think it's worth going through C-Reduce and hacking special cases for #include lines into the relevant passes, though I will keep this in mind in the future.
John On 2/8/16 10:17 AM, Tzafrir Poupko wrote:
Hi All, I'm reducing non pre-processed files, and notice the following 'funny' bug. In the project I'm reducing, there is a include file #include "folderA/folderb.h" which includes all the files in folder b, so the content is for example #nclude "folderA/folderb/file1.cpp" #include "folderA/folderb/file2.cpp" #include "folderA/folderb/file3.cpp" After running creduce on the source and the headers, it turns out my code only depends on #include "folderA/folderb/file3.cpp" If I now run creduce and let it perform all the passes, one of the passes deletes single characters from a line changing this include line to #include "folderA/folderb.cpp" And actually throws me back in the reduce process. Maybe this pass can check and not shorten include lines? Tzafrir