Re: Removing GCC warnings from flex- and bison- generated C code

Fergus Henderson <fjh@cs.mu.oz.au>
12 Jan 2004 13:30:23 -0500

          From comp.compilers

Related articles
Removing GCC warnings from flex- and bison- generated C code zender@uci.edu (Charlie Zender) (2004-01-09)
Re: Removing GCC warnings from flex- and bison- generated C code haberg@matematik.su.se (2004-01-12)
Re: Removing GCC warnings from flex- and bison- generated C code fjh@cs.mu.oz.au (Fergus Henderson) (2004-01-12)
Re: Removing GCC warnings from flex- and bison- generated C fjh@cs.mu.oz.au (Fergus Henderson) (2004-01-16)
Re: Removing GCC warnings from flex- and bison- generated C code zender@uci.edu (Charlie Zender) (2004-01-16)
| List of all articles for this month |

From: Fergus Henderson <fjh@cs.mu.oz.au>
Newsgroups: comp.compilers
Date: 12 Jan 2004 13:30:23 -0500
Organization: The University of Melbourne
References: 04-01-045
Keywords: lex, yacc
Posted-Date: 12 Jan 2004 13:30:22 EST

Charlie Zender <zender@uci.edu> writes:


>I am trying to get a code to compile warning free with GCC so that I
>may use the -Werror option to help find new bugs. The remaining
>warnings in my code all appear to be generated when the lexer and
>parser files are compiled.


In that case, consider compiling those files with -Wno-error.


>1. Are flex and bison intended to produce files that are warning free
> code when compiled with stringent compiler options?


Regardless of whether they were originally intended to do that, it is
clearly a useful feature, so it seems very likely that the flex and
bison maintainers would be happy to accept patches to support this.


>2. do other lexer/parsers generate these warnings (see below)
> of does this indicate a poorly written/incomplete .l and .y file
> on my part?


Most of the warnings shown indicate issues with bison/flex, not with
your code.


However, it is possible to add declarations to your code which will
supress these warnings. These declarations can go either
in the declarations section of your .l or .y files, or in a
header file which is included from those.


>ncap_yacc.c: In function `yyparse':
>ncap_yacc.c:1216: warning: implicit declaration of function `yylex'


You can avoid that one by explicitly declaring yylex() in the declaration
section at the start of your .y file:


%{
int yylex(void);
%}


>ncap_lex.c:1034: warning: no previous prototype for `yylex'


Likewise, though this time it needs to be declared at the start of the .l file.


>ncap_lex.l: In function `yylex':
>ncap_lex.l:670: warning: implicit declaration of function `yy_flex_realloc'


You can avoid that one by declaring yy_flex_realloc().


>ncap_lex.c: In function `yy_init_buffer':
>ncap_lex.c:2595: warning: implicit declaration of function `fileno'


That one can be fixed by compiling with -D_POSIX_SOURCE or including
`#define _POSIX_SOURCE 1' in the declaration section of your .l file.


>ncap_lex.c: At top level:
>ncap_lex.c:2840: warning: no previous prototype for `yyget_lineno'
>ncap_lex.c:2849: warning: no previous prototype for `yyget_in'
>ncap_lex.c:2857: warning: no previous prototype for `yyget_out'
>ncap_lex.c:2865: warning: no previous prototype for `yyget_leng'
>ncap_lex.c:2874: warning: no previous prototype for `yyget_text'
>ncap_lex.c:2883: warning: no previous prototype for `yyset_lineno'
>ncap_lex.c:2895: warning: no previous prototype for `yyset_in'
>ncap_lex.c:2900: warning: no previous prototype for `yyset_out'
>ncap_lex.c:2905: warning: no previous prototype for `yyget_debug'
>ncap_lex.c:2910: warning: no previous prototype for `yyset_debug'
>ncap_lex.c:2916: warning: no previous prototype for `yylex_destroy'


Those warnings can all be eliminated by declaring prototypes
for the corresponding functions.


--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.