[antlr-interest] 0xcdcdcdcd myth with antlr base tree pointer u

[Jim Idle]

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