Re: Ungraceful handling of fatal flex errors

From: dom(at)idealx(dot)com, dom(at)idealx(dot)com
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Ungraceful handling of fatal flex errors
Date: 2001-01-29 10:39:03
Message-ID: 20010129113903.A14091@seccotine.ird.idealx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 string to 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(at)kilimandjaro(dot)dyndns(dot)org>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Klimov 2001-01-29 10:57:08 Re: Talking about Solaris 7
Previous Message Pete Forman 2001-01-29 08:39:22 Re: beta3 Solaris 7 (SPARC) port report