I've run into http://code.google.com/p/pyglet/issues/detail?id=485. A
patch with a fix is attached to the issue, but I am not sure who knows
much about the wraptypes module to check it.
Trying to execute gengl.py failed in bits/wchar.h for me, trying to parse:
#elif L'\0' - 1 > 0
It lexed it into an identifier L followed by a character constant 0.
In some parts of the grammar this mistake was harmless, but when it
encountered it as part of an #elif expression, it caused it to crash
when trying to evaluate it.
The attached patch for wraptypes/preprocessor.py:
1) Makes CHARACTER_CONSTANT have priority over IDENTIFIER when lexing.
This should be harmless because L' is never valid except as the start
of a character constant.
2) Adds a character_constant rule to ConstantExpressionGrammar, which
turns a lexed CHARACTER_CONSTANT into a numeric value.
3) Adds a character_constant expansion to the primary_expression grammar rule.
Even with this patch, wraptypes cannot accurately parse the intent of
the expression, since doing the math on a Python integer will not be
useful for determining whether the wchar_t type underflows. But the
module already makes a number of concessions like this (e.g. all
identifiers evaluate to 0), so this doesn't seem like too big a deal -
the ability to parse the file at all would seem to trump the inability
to be an entire C preprocessor.
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en.
