Re: [HACKERS] Ungraceful handling of fatal flex errors

2001-02-05 Thread dom
> > > scan.c:2145: warning: `yy_fatal_error' defined but not used > > I have a sneakier idea to avoid the warning. [...] > > #define fprintf(file,fmt,msg) elog(FATAL, "%s", (msg)) Meaning no disrespect : yuck... IMHO this is asking for trouble whenever someone decides to use another yacc. O

Re: [HACKERS] Ungraceful handling of fatal flex errors

2001-01-29 Thread dom
> This is flex, not yacc, and our lexer has been flex-only for a long > time. It's possible that the hack would break in a future version > of flex, but I doubt it. What else is a lexer going to use fprintf > for? Hmm, well of course you are right... (and I could use some sleep too :-). OK, t

Re: [HACKERS] Ungraceful handling of fatal flex errors

2001-01-29 Thread Tom Lane
[EMAIL PROTECTED], [EMAIL PROTECTED] writes: >> #define fprintf(file,fmt,msg) elog(FATAL, "%s", (msg)) > Meaning no disrespect : yuck... IMHO this is asking for trouble > whenever someone decides to use another yacc. This is flex, not yacc, and our lexer has been flex-only for a long time. I

Re: [HACKERS] Ungraceful handling of fatal flex errors

2001-01-27 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > A fatal scanner error (likely a memory exhaustion problem) causes a > straight exit() without clean up, which causes a system-wide restart. > This should fix it: > *** scan.l 2001/01/24 19:43:03 1.85 > --- scan.l 2001/01/27 14:14:29 > *

[HACKERS] Ungraceful handling of fatal flex errors

2001-01-27 Thread Peter Eisentraut
A fatal scanner error (likely a memory exhaustion problem) causes a straight exit() without clean up, which causes a system-wide restart. This should fix it: *** scan.l 2001/01/24 19:43:03 1.85 --- scan.l 2001/01/27 14:14:29 *** *** 55,60 --- 55,62 /* No reas