Hi @ronaldnie!  Sorry for taking so long to get back to you here.

> I checked several xdress modules and could not find an easy way to pass rc to pycparser_parse. 

I am not sure that it is going to be trivial.  But it shouldn't be hard either.  I think that the astparsers plugin probably just needs a `setup()` method which adds things to the includes, defines, and undefines list based on what the value of parser actually is.  In truth, `clang_includes` should probably have been done this way.  Adding a `pycparser_includes` run control parameter and argument is probably OK too, since it at least matches the way things are done now.

> Another idea would be to pass rc to all three parse function so that the function signature would be more uniform, assuming rc is available at the points these functions are called.

This is exactly what we are trying to avoid.  The plugin code that *runs* xdress should be strictly separate from the code that implements xdress functionality.  In short, no functions should ever see an rc.

> The reason to have a default value for the rc argument is to minimize the effort for unit tests.

It is better to minimize user effort than effort on the unit tests.  Besides, I think that not having functions take an rc makes it easier to unit test because then the unit tests don't need to set up an rc to be able to run.

I hope that this helps explain some of the design decisions that were made.