gnupic: Re: special numbers
Subject:
Re: special numbers
From:
pico ####@####.####
Date:
10 Sep 2004 16:25:05 +0100
Message-Id: <4141C747.1050100@sourceforge.net>
For a unknown reason , the REJECT don't work as expected in this
particular line.
Replacing the REJECT with a yyless(0) has resolved the problem.
I have made little cleanup's. Take care for possible line wrapping
from the email client.
I don't like Scott's suggestion because i don't see the proposed
solution. Craig, please correct my, if i wrong.
I admit, that this is a strange hack, but on the other side, the
directive is not parsed from the yacc(bison) parser, but afterwards
from ordinary C code after some possible macro and define substitution.
If someone defines
cr set .10 ; carrige return
and uses list p=16cr64
this results int <IDENTIFIER> <IDENTIFIER> '=' <NUMBER> <NUMBER> <NUMBER>
.
How do you want resolve this to the 16cr64, or would you completly
rewrite the bison parser.
6a7
> %x identifier
176a178,181
> <identifier>[^ \t\n\r;,]+ { BEGIN(0); goto id; }
> <identifier>. /* ignore */
> [0-9]{2,2}[a-z].* { if (force_decimal) BEGIN(identifier);
yyless(0); }
> processor/[ \t][0-9] { BEGIN(identifier); goto id; }
179c184
< force_decimal = 1;
---
> force_decimal = 1; id:
336,341d340
< 1[24678][CFHL0][CERV]?[0-9X][0-9X][0-9]?[0-9ABC]? {
< /* Ugh. As a special case, treat processor names, such as 16C84
< as identifiers rather than as hex numbers. */
< yylval.s = strdup(yytext);
< return IDENTIFIER;
< }
