[antlr-interest] 0xcdcdcdcd myth with antlr base tree pointer u
Jim Idle
jimi at temporal-wave.com
Fri Jun 26 10:46:46 PDT 2009
I will make any fixed next week. I don't need your code. The pointers
that are not initialized are set to that value by windows debut
malloc. You won't be able to rely on that value in production mode or
other platforms. The user pointers are not initialiZed deliberatly as
they are for you to use. So if you need them to be null sometimes then
you should set them in your own version of next token or whatever. I
can probably safely initialize them at create time though. If you are
referring to other pointers then inwill make sure they are set to
null. I changed to malloc from calloc and some pointers are not
imitialiZed as a result and I should fill them in. I am back at home
neztbqeek and take care of al of this.
Jim
On Jun 26, 2009, at 1:24 PM, "Xie, Linlin" <linlin.xie at siemens.com>
wrote:
> Hi Jim,
>
>
>
> I’ve noticed that that empty pointers are all (am I right?) initiali
> zed to be 0xcdcdcdcd by default. Looks like it’s a debugging value c
> oming from the C runtime library. I wonder if you have your reason f
> or this to work this way, or better to initialize them to be 0? it’d
> be helpful for us that we don’t have to check against this value wh
> ich is perhaps not platform independent.
>
>
>
> Also, I made some small changes in the antlr 3.1.3 to fix the
> previous two bugs I mentioned, and a change to make the @after
> action work for our purpose. I wonder if I should submit to the
> antlr repository to get checked if they are good fixs, and also I
> wonder we can push you a little bit to get @after supported soon J?
>
>
>
> Thanks a lot.
>
> Regards,
>
> Linlin
More information about the antlr-interest
mailing list