3. [flex] Start Conditions und String matchen

[flex] Start Conditions und String matchen

  • V

    Ich entwickle gerade mit flex und bison eine kleine Template-Sprache ähnlich wie PHP und Co. Das ganze soll vorallem dazu dienen das ich etwas mehr Einblick in die Praxis mit Lexern und Parsern erhalte.

    Jetzt habe ich aber folgendes Problem. Ich benutze Start Conditions um das analysieren erst zu starten wenn ein "Script-Tag" gefunden wird:

    "<%" { BEGIN(IN_TPL); }

    Innerhalb der Script-Tags soll man nun auch mit Strings arbeiten können wie man das von so ziemlich jeder Programmiersprache her kennt. Ich habe also eine Regel zum matchen vom Beginn eines Strings:

    <IN_TPL>\" { string_buf_ptr = string_buf; BEGIN(IN_STRING); }

    Ich beginne demnach eine neue Ebene "IN_STRING". Innerhalb dieser Ebene behandele ich nun die Besonderheiten der Strings:

    <IN_STRING>.    { *string_buf_ptr++ = *yytext; }
<IN_STRING>\\n  { *string_buf_ptr++ = '\n'; }
<IN_STRING>\\t  { *string_buf_ptr++ = '\t'; }
<IN_STRING>\\\" { *string_buf_ptr++ = '\"'; }

    Damit ich das Ende des String ausfindig machen kann gibt es ebenfalls eine Regel, und genau da klemmts momentan:

    <IN_STRING>\" { *string_buf_ptr = 0; printf("string \"%s\"\n", string_buf); BEGIN(IN_TPL); }

    Hier meldet mir flex: "warning, rule cannot be matched".
    Ich denke mal das die Regel für den Begin eines Strings diesen "überlagert" jedoch befinde ich mich doch aber in einer anderen Ebene? Hab auch schon das Manual durchsucht und auch google gequält aber es gibt nur Beispiele wo die Regel für einen Stringbeginn nicht mit einer Start Condition in Verbindung steht, quasi nur im INITIAL State. Gibt es villeicht ein "logischens Und" für Start Conditions (e.g. <IN_TPL+IN_STRING>)? Finde immer nur das "logische Oder", also die Komma separierte Liste von Start Conditions (e.g. <IN_TPL,IN_STRING>) und das funktioniert an der Stelle natürlich nicht.
    Vielleicht kann mir ja jemand sein Licht borgen 🤡

    Gut Schuß
    VuuRWerK 😉

    0
  • B

    Ist das eventuell nur ein Reihenfolgeproblem? Du hast die Defaultregel (für '<IN_STRING>.') am Anfang.

    0
  • V

    Aha! Danke für das Licht 💡 🙂
    Also kann man an dieser Stelle sagen, das eine Regel mit "." stärker bindet als eine genauer definierte, vielen Dank!

    Gut Schuß
    VuuRWerK 😉

    0
  • B

    Ich dachte eigentlich eher daran, dass die Regeln, wenn mehrere anwendbar sind, von oben nach unten angewendet werden. Die Default-Regel sollte also weiter unten stehen, damit die spezielleren Regeln zuerst zum Zuge kommen können.

    0
  • V

    Genau, damit diese Regeln sich quasi um die "Überbleibsel" kümmern können, haste recht 🙂

    Gut Schuß
    VuuRWerK 😉

    0
  • K

    Ist schon laenger her, aber ich glaube, die laengste Regel wird als erstes angewendet. "laengste" ist im Sinne von Characters des gematchten Wortes zu verstehen.

    das eine Regel mit "." stärker bindet als eine genauer definierte

    Diese Regel ist auch eine genau definierte.

    edit: einfach nachlesen http://dinosaur.compilertools.net/lex/index.html

    Lex can handle ambiguous specifications. When more than one expression can match the current input, Lex chooses as follows:

    1. The longest match is preferred.

    2. Among rules which matched the same number of characters, the rule given first is preferred.

    0
  • B

    ***

    Edit: Äh ja. Dann ist mein Posting wohl redundant 🙂

    0
Anmelden zum Antworten