Your message dated Sat, 06 Sep 2008 10:10:59 -0500
with message-id <[EMAIL PROTECTED]>
and subject line According to upstream, this is not a bug in flex
has caused the Debian Bug report #298302,
regarding flex: fails recognizing the right rule
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
298302: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298302
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: flex
Version: 2.5.31-31
Severity: important


In a particular (but common) situation, it seems to me that flex recognizes a
rule in wich appear a character that is not present in the parsed text.
This situation is described bellow.

Here is the flex input file :

/************************ FLEX INPUT FILE ************************/
%{
%}

%option outfile="myLexer.c"
%option stack
%option noyywrap
%option debug

%x BETWEEN_QUOTES

ANY_NON_QUOTED_CHAR                     "|"
QUOTE                                   '
FIRST_CHAR_SET                          [a-z]
SECOND_CHAR_SET                         [#]
QUOTED_CHAR                {FIRST_CHAR_SET}|{SECOND_CHAR_SET}

%%

<INITIAL>{
   {QUOTE}                             yy_push_state(BETWEEN_QUOTES);
}
<BETWEEN_QUOTES>{
{ANY_NON_QUOTED_CHAR}{QUOTED_CHAR} printf("The ANY_NON_QUOTED_CHAR has been read !!");
   {QUOTED_CHAR}+
   {QUOTE}                             yy_pop_state();
}

%%

/************************* END OF FLEX INPUT FILE *****************/


The aim is to generate a parser that is able to read a quoted string
made up of :
   - Rule at line 24: quoted characters, ie characters coming from the
   union of two sets called 'FIRST_CHAR_SET' and 'SECOND_CHAR_SET' ;
   - Rule at line 23: a special character (called 'ANY_NON_QUOTED_CHAR')
   followed by a quoted character (this rule may be use to parse
   escape sequence in quoted strings for example).

When the parsed text is a QUOTE followed by a FIRST_CHAR_SET character
followed by a QUOTE (for example, the string 'a'), then rule at line 24 is
matched (which seems correct).
When the parsed text is a QUOTE followed by a SECOND_CHAR_SET character
followed by a QUOTE (for example, the string '#'), then rule at line 23 is
matched whereas the special ANY_NON_QUOTED_CHAR does not appear in the parsed
text.
In this situation, rule at line 24 should have been matched.

Here is an exemple of the parser execution output (in debug mode) :



--(end of buffer or a NUL)
'a'
--accepting rule at line 20 ("'")
--accepting rule at line 24 ("a")
--accepting rule at line 25 ("'")
--accepting default rule ("
")

--(end of buffer or a NUL)
'#'
--accepting rule at line 20 ("'")
--accepting rule at line 23 ("#")
--accepting rule at line 25 ("'")
--accepting default rule ("
")
The ANY_NON_QUOTED_CHAR has been read !!
--(end of buffer or a NUL)



If the parsed quoted string contains more than one character, then the
parser seems to work correctly. For example :



--(end of buffer or a NUL)
'a#'
--accepting rule at line 20 ("'")
--accepting rule at line 24 ("a#")
--accepting rule at line 25 ("'")
--accepting default rule ("
")

--(end of buffer or a NUL)
'#a'
--accepting rule at line 20 ("'")
--accepting rule at line 24 ("#a")
--accepting rule at line 25 ("'")
--accepting default rule ("
")

--(end of buffer or a NUL)



I've tried to put other characters in the SECOND_CHAR_SET (like [A-Z] instead
of [#]) but the execution remains the same.

I've also noticed that if QUOTED_CHAR is not defined as an union (if it is defined like [a-z#] for example) or if rules at line 24 and 23 are swapped (rule at line 24 goes at line 23), then the parser works correctly.


Hope I've not misunderstood something and that this report will help to
solve this bug.




-- System Information:
Debian Release: 3.1
 APT prefers testing
 APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.18-bf2.4
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages flex depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  m4                          1.4.2-1      a macro processing language

-- debconf information:
* flex/upgrade/pre_2.5.5: true



--- End Message ---
--- Begin Message ---
Hi,

        This has to do with the lack of parentheses around the
 substituted rule. It is not a bug in flex. The solution is
 to use explicit parenthesis around the alternation.

        manoj
-- 
Very few profundities can be expressed in less than 80 characters.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--- End Message ---

Reply via email to