Double pointers badly handled about pycparserext HOT 10 CLOSED

Sorry--I don't currently have time to look at or help with this. But I'd be happy to take a patch.

from pycparserext.

I have the same issue. I need pycparserext to parse a real-world C source code (QEMU) with uses GNU extensions. It chokes on function prototypes containing pointer to pointer params like this:

typedef struct Error {
    int dummy;
} Error;
void func_with_pp_param(const char *, Error **);

Adding a name to the last param, i.e.

void func_with_pp_param(const char *, Error **p);

makes the parsing magically work. Vanilla CParser works as well.

Any chances to get a support for such constructs in pycparserext?

from pycparserext.

Sure, I'd be happy to review a patch.

from pycparserext.

After spending several evenings learning PLY basics, I suspect some conflict in the pycparser/pycparserext grammar. Pycparserext:state107 behaves differently compared to pycparser:state77. That's where the things actually go wrong. My bet is that commenting out p_xxx_declarator_2 resolves that conflict.

To be able to spot the issue, one need to analyze low-level PLY parsing tables which is beyond my current knowledge level. Anyway, I'll continue to investigate.

BTW, enabling debug output with the following code:

gnu_parser = GnuCParser(yacc_debug=True)

dumps a lot of conflict warnings:

Generating LALR tables
WARNING: 121 shift/reduce conflicts
WARNING: 8 reduce/reduce conflicts
WARNING: reduce/reduce conflict in state 224 resolved using rule (primary_expression -> gnu_statement_expression)
WARNING: rejected rule (statement -> gnu_statement_expression) in state 224

I'm not sure how serious they are and whether the original parser has them too...

from pycparserext.

Those do look significant. Also, thanks for pointing out yacc_debug=True--I did not know about this. I don't have a lot of time to debug this myself, but I welcome any progress you might be able to make. One aspect of this is that pycparser is a moving target, so these may have crept in as the code kept changing out from under pycparserext.

from pycparserext.

I should have a fix ready in PR #37

from pycparserext.

@jackrosenthal Thank you for fixing that! This issue was a major roadblock in a project I'm working on. I'll test your fix later today and report the result.

from pycparserext.

@jackrosenthal I just tested your fix - it works like a charm, even for complex sources like QEMU. Unit tests (python -m pytest) do pass as well. Thank you very much!

@inducer Andreas, would you kindly merge the PR #37? I'll in turn contribute an appropriate unit test covering this corner case.

from pycparserext.

@maximumspatium Done. I would much appreciate a PR with a unit test for this. Thanks for offering.

from pycparserext.

Closing via merge of #37.

from pycparserext.