Closed snemes closed 2 years ago
Thanks for the well crafted example.
The main issue is the expansion of the macro with arguments in the #if. The current JavaCC parser can't parse additional injected text without instantiating a new parser. Calling a new parser for every expansion of a macro with arguments could be very slow.
I've worked out a fix that is a compromise. The parser will attempt to simplify expressions after macro expansion and concatenation. I suspect there will still be some header files that won't parse correctly. I also suspect the fix will address some other long standing cparser issues. The fix will need to go through our review process as there was some refactoring required to a hand rolled expression parser. We'll try and push it to github soon.
Describe the bug The Ghidra C preprocessor/parser fails to evaluate certain preprocessor expressions correctly. Originally thought to be related to #1421, but turned out to be a separate issue.
To Reproduce Steps to reproduce the behavior:
Expected behavior Ghidra should be able to parse this test file without problems. Most of lines in the test file were borrowed from the standard Windows header file "winapifamily.h", with some further lines added to be able to localize and trigger he problem. The error message triggers because the struct at the end of the .h file references the WORD data type (Ghidra already has a built-in lowercase "word" data type, but that was intentionally not used here), which is defined right above the struct definition inside an
#if
conditional preprocessor block.Screenshots N/A
Attachments test.h - test.zip
CParserPlugin.out - CParserPlugin.zip
Environment (please complete the following information):
Additional context The attached CParserPlugin.out file shows the problematic part here:
So the expression
(1 | 2) & 2 == 2
incorrectly evaluates to False according to the C preprocessor, so the rest of the#if
block is skipped, thus the WORD data type is not getting defined, leading to the error later in the struct definition.