Conversation
| void nullNodeInvalidLevel() { | ||
| // a "<<<NULL>>>" line whose indentation maps to level 0 must not index tree[-1] | ||
| const char* clang = "`-FunctionDecl 0x1 <a.cpp:1:1, col:34> col:6 foo 'void ()'\n" | ||
| "`-<<<NULL>>>\n"; | ||
| ASSERT_EQUALS("void foo ( ) ;", parse(clang)); | ||
| } |
There was a problem hiding this comment.
This is an AI review. Take it with a grain of salt and feel free to reject it by resolving the comment.
The fix looks correct. I verified that nullNodeInvalidLevel fails on main (built with -D_GLIBCXX_ASSERTIONS: Assertion '__n < this->size()' failed on tree[level - 1]) and that TestClangImport passes with this PR.
Nit: the test function is defined between run() and the parse() helper. All the other test functions come after the helpers, and the description says it goes "next to the existing crash() case". Maybe move it to just after crash() at the end of the class?
There was a problem hiding this comment.
What is the status of ClangImport? As far as I see, it has been abandonded for years and is probably unusable. We might want to ditch it instead of wasting time on probably AI-generated "fixes".
There was a problem hiding this comment.
Done, moved it to just after crash() at the end of the class and pushed.
There was a problem hiding this comment.
Yes, I use AI tooling to help find and prepare these, and I'm responsible for what gets submitted here. Whether ClangImport is worth keeping is your call. The change itself is just the same bounds guard the normal-node path already applies, against an OOB read that's easy to hit through --clang, so it stays minimal. If you'd rather retire the importer than keep patching it, I'm fine with that and happy to close this.
There was a problem hiding this comment.
This is an AI review take it with a grain of salt. Please feel free to reject it by clicking on Resolve button
Thanks, the update looks good to me.
FYI: #8907 also adds a test right after crash() and a TEST_CASE line in the same place in test/testclangimport.cpp, so whichever of the two PRs is merged second will get a trivial merge conflict.
Signed-off-by: nussaiba shaikh <nussaibah@bugqore.com>
I feel that it's only experimental and I feel that reading the AST from the debug output is not a proper approach. clang has a json output instead nowadays but it's a significant rewrite to use that. imho, lets ditch it. |
an alternative instead of ditching it might be to see if we can actually make it work by using AI. however it then has to be done without more manual work (in particular reviews). we could add a comment in the clangimport.cpp that AI fixes in that particular file are OK and we will not manually review this..? how do we extend quality assurance beyond AI reviews?
|
3 participants
parseClangAstDump indexes tree[level - 1] for a
<<<NULL>>>line without thelevel == 0 || level > tree.size()check that the sibling path for normal nodes applies a few lines below, so a dump whose stray null child sits at the top indentation makes level zero and reads tree[-1]. Feeding a crafted or truncated clang AST dump through --clang trips a heap-buffer-overflow (confirmed under ASAN) in that loop. This adds the same guard the normal-node path already uses, plus a regression test next to the existing crash() case.