Issue 485 in pyglet: Wrapper generation (e.g. gengl.py) fails to parse L-prefaced character literals

[codesite...@google.com]

Status: New
Owner: ----

New issue 485 by joe.wreschnig: Wrapper generation (e.g. gengl.py) fails to
parse L-prefaced character literals
http://code.google.com/p/pyglet/issues/detail?id=485

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.

Attachments:
wraptypes-char-constant-fix.diff 1.4 KB

--
You received this message because you are subscribed to the Google Groups "pyglet-issues" group.
To post to this group, send email to pyglet...@googlegroups.com.
To unsubscribe from this group, send email to pyglet-issue...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyglet-issues?hl=en.