graminit.h is an header file associating Grammar entities to their values, example:

#define stmt 269

Problem: defines symbols have no prefix and cause compilation issues on regular C code depending where graminit.h is included. Example with ast.c:

static int
validate_stmt(stmt_ty stmt)
{ ... }

"#define stmt 269" causes a compilation issue, the preprocessor replaces the code with:


static int
validate_stmt(stmt_ty 269)
{ ... }

... which is invalid.


Another example:

        return validate_expr(exp->v.IfExp.test, Load) &&
            validate_expr(exp->v.IfExp.body, Load) &&
            validate_expr(exp->v.IfExp.orelse, Load);

The preprocessor replaces "exp->v.IfExp.test" with "exp->v.IfExp.305" which is invalid...



The compile.h header file works around the issue by redefining 3 constants but using "Py_" prefix:

/* These definitions must match corresponding definitions in graminit.h.
   There's code in compile.c that checks that they are the same. */
#define Py_single_input 256
#define Py_file_input 257
#define Py_eval_input 258

For comparison, graminit.h uses:

#define single_input 256
#define file_input 257
#define eval_input 258


There are different solutions:

* Do nothing: require to include graminit.h at the right place
* Add a prefix to all symbols, ex: test => Py_test, grammar_test, etc.
* Rename problematic names like 'test' and 'stmt'
* Fix C code to avoid problematic name: 'test' is an an attribute name of a node struct...

Note: "static const int single_input = 305;" cause a complation error on "case single_input": "case label does not reduce to an integer constant".


IMHO adding a prefix would be a nice enhancement and a good compromise. It only impacts the four C files which include graminit.h: future.c, ast.c, parsetok.c and parsermodule.c.