Re: an "internal compiler error"

[Jose E. Marchesi]

> Jose E. Marchesi wrote:
>> > $ poke -l /tmp/fuzz1.pk 
>> > 1:1: internal compiler error: input buffer overflow, can't enlarge buffer 
>> > because scanner uses REJECT
>> > Important information has been dumped in /tmp/pokecyGfH0.
>> > Please attach it to a bug report and send it to poke-devel@gnu.org.
>> > Aborted
>> >
>> > Credit: AFL++4.00.c
>> 
>> Yes we are aware of that.
>> 
>> It is a fatal error that flex generates when it needs to grow a buffer
>> but the lexer uses REJECT (as in our case).
>
> So, in this particular case, wouldn't it be better to lonjmp() back to the
> main REPL prompt, rather than to ask for a bug report to poke-devel?

Yes, but I don't think we can discriminate between that particular error
and other fatal errors raised by flex.

See YY_FATAL_ERROR in libpoke/pkl-lex.l.  The only argument we get in
that macro is the error message.  We could scan it and try to determine
whether we should longjmp or abort, but that would be rather fragile
IMO.

So we would need to recover in all sort of flex fatal errors.  Since a
new scanner is created each time pk_compile_* is invoked, that may be
ok.