Hi,

> foo->type is uninitialized (details below), which can cause the compare at
> the beginning of the function to produce potentially undesired results.

No, that one's OK. The only uninitialized parser nodes being written are
the ones that aren't referenced (at least in theory, and parsing seems to
work, except for some problems that appear to be algorithmic in nature).

If you want to resolve this: The 'correct' solution would be to write out
and read the nodes as a binary tree (i.e. recursively by tracking the
places they reference) rather than as a list. If you still get
uninitialized reads, then it's either a bug or you forgot to check for
state->parser_valid first.

llap,
 Christoph


Reply via email to