[antlr-interest] Bug in ANTLR C runtime - Incorrect getCharPositionInLine on first line

[Jim Idle]

Yes - you have to special case it. However, you only ever come across this while developing really ;-)

Jim

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Ales Teska
> Sent: Thursday, October 08, 2009 5:33 PM
> To: antlr-interest at antlr.org
> Subject: [antlr-interest] Bug in ANTLR C runtime - Incorrect
> getCharPositionInLine on first line
> 
> Hi,
> 
> I'm using ANTLR3 in one of my project and it seems that I found small
> bug in ANTLR C (version 3.2, 3.1.3 is also corrupted).
> I do not know if this is correct way of reporting bugs but ...
> 
> ANTLR3 C runtime returns incorrect values of CharPositionInLine for
> tokens on first line of input. This is eventually propagated to tokens.
> I wrote small program to demonstrate this behavior - it is available
> here: http://devel-www.cyber.cz/files/tmp/antlrc3-bug-pack.zip
> 
> Bug causes token stream post-processing a little bit more complicated
> than it can ideally be ...
> 
> Here is expected output (produced by Python target).
> First character is from input.txt, second is result of
> getCharPositionInLine():
> 
> --- cut --- cut --- cut ---
> 1 0
> 2 2
> 3 4
> \n 5
> 1 0
> 2 2
> 3 4
> \n 5
> --- cut --- cut --- cut ---
> 
> and here is actual output from C target:
> 
> --- cut --- cut --- cut ---
> 1 4294967295
> 2 1
> 3 3
> \n 4
> 1 0
> 2 2
> 3 4
> \n 5
> --- cut --- cut --- cut ---
> 
> Please notice that first token has undefined value in
> getCharPositionInLine() and rest till end of line is shifted by -1.
> 
> Workaround is to set ctx->pLexer->input->charPositionInLine to zero
> after constructing lexer and before actual lexing/parsing.
> 
> Regards,
> Ales Teska