Re: Ungraceful handling of fatal flex errors - Mailing list pgsql-hackers

From dom@idealx.com, dom@idealx.com
Subject Re: Ungraceful handling of fatal flex errors
Date
Msg-id 20010129113903.A14091@seccotine.ird.idealx.com
Whole thread Raw
In response to Re: Ungraceful handling of fatal flex errors  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 
> > 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. One should never ever
use the preprocessor to do what it was originally intended for
:-). Why not just make a useless statement calling yy_fatal_error ? 

--- scan.l.orig    Mon Jan 29 11:36:56 2001
+++ scan.l    Mon Jan 29 11:27:28 2001
@@ -532,6 +534,9 @@       because input()/myinput() checks the non-nullness of parseCh       to know when to pass the
stringto lex/flex */    parseCh = NULL;
 
+
+    /* Make a bogus use of yy_fatal_error to avoid spurious warning */
+    (void) &yy_fatal_error;    /* initialize literal buffer to a reasonable but expansible size */    literalalloc =
128;

-- 
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>
        Dominique Quatravaux <dom@kilimandjaro.dyndns.org>


pgsql-hackers by date:

Previous
From: "Oliver Elphick"
Date:
Subject: Stuck Spinlock (fwd) - m68k architecture, 7.0.3
Next
From: Thomas Lockhart
Date:
Subject: Re: Re: Format of the Money field