Algunos patrones de contexto posterior no pueden reconocerse correctamente y generan mensajes de aviso ("contexto posterior peligroso"). Estos son patrones donde el final de la primera parte de la regla reconoce el comienzo de la segunda parte, tal como "zx*/xy*", donde el 'x*' reconoce la `x' al comienzo del contexto posterior. (Fíjese que el borrador de POSIX establece que el texto reconocido por tales patrones no está definido.)
Para algunas reglas de contexto posterior, partes que son de hecho de longitud fija no se reconocen como tales, resultando en la pérdida de rendimiento mencionada anteriormente. En particular, las partes que usan `|' o {n} (tales como "foo{3}") siempre se consideran de longitud variable.
La combinación de contexto posterior con la acción especial `|' puede producir que el contexto posterior fijo se convierta en contexto posterior variable que es más caro. Por ejemplo, en lo que viene a continuación:
%%
abc |
xyz/def
El uso de `unput()' invalida yytext e yyleng, a menos que se use la directiva `%array' o la opción `-l'.
La concordancia de patrones de NUL's es substancialmente más lento que el reconocimiento de otros caracteres.
El ajuste dinámico del buffer de entrada es lento, ya que conlleva el reanálisis de todo el texto reconocido hasta entonces por el (generalmente enorme) token actual.
Debido al uso simultáneo de buffers de entrada y lecturas por adelantado, no puede entremezclar llamadas a rutinas de <stdio.h>, tales como, por ejemplo, `getchar()', con reglas de flex y esperar que funcione. Llame a `input()' en su lugar.
La totalidad de las entradas de la tabla listada por la bandera `-v' excluye el número de entradas en la tabla necesarias para determinar qué regla ha sido emparejada. El número de entradas es igual al número de estados del DFA si el analizador no usa REJECT, y algo mayor que el número de estados si se usa.
REJECT no puede usarse con las opciones `-f' ó `-F'.
El algoritmo interno de flex necesita documentación.