Parsing `va_arg(foo, type)`

[charmoniumQ]

I was hoping to parse the following code.

// Fake stub of stdarg.h more amenable to pycparser
typedef void* va_list;

// The actual code I want to parse
int foo(int f, ...) {
  va_list ap;
  va_start(ap, f);
  va_arg(ap, int); // <--- ParseError: before: int
  va_end(ap);
}

I understand that pycparser can parse function-like syntax forms, so long as none of the arguments are type-names. I was wondering what part of the code causes this behavior (it's not obvious to me from reading the _c_ast.cfg), and would you accept a pull request that loosens this behavior, i.e., foo(int) would be valid (so that va_arg can be supported)?

Some rationale:

• Loosening this would cause some syntactically invalid C code to parse in pycparser, but pycparser does not seem like the right tool to determine syntactic validity; one may be be better off using gcc/clang for syntatic validity. I think most applications for pycparser are writing code-refactoring and source-to-source code transformations. If you wanted that kind of validity, you can easily check that as a property of the AST (no IDs should be type names).
• va_arg is technically in C99, so it's not some random GCC extension, and pycparser already supports parsing the ellipsis, but ellipsis without var_arg is kind of useless.

[eliben]

While va_arg is in C99, it's a macro so it should be handled by the preprocessor. You can already parse this using the standard provided fake headers (see the README).

In the general case taking types instead of other identifiers can be very tricky in C (which is probably why this is delegated to a macro in the standard).

[charmoniumQ]

The provided macro ignores the type of the argument, so this information is not available in the AST.

[eliben]

I don't object, but it may be tricky to add this parsing rule without introducing more parser conflicts. PRs welcome