Re: #if !_GL_CONFIG_H_INCLUDED breaks flex generated lexers, FYI

[Bruno Haible]

Hello Paul,

> This recent commit:
> 
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=8ad7bc671475d3291df10a1a1d64fddfd30e5175
> 
> renders Flex generated lexers uncompilable. If you use GnuLib, you're using 
> wrappers around standard headers like stdio.h. The recent commit added lines 
> to such wrappers like this:
> 
> #if !_GL_CONFIG_H_INCLUDED
>  #error "Please include config.h first."
> #endif
> 
> The problem is a Flex-generated lexer's .c file has:
> 
> /* begin standard C headers. */
> #include <stdio.h>
> #include <string.h>
> #include <errno.h>
> #include <stdlib.h>
> 
> generated near the top and the project's include path is set to pick up the 
> wrapper headers first — and the lexer's .c file doesn't have:
> 
> #include "config.h"
> 
> before the include of the wrapper headers, so it complains.

Thanks for the heads-up.

The project's -I options should pick gnulib's generated .h files first;
so, that is OK and should not be changed.

What can reasonably be changed is:

  (a) The input to flex can be changed. Add this to your input file:

       %top {
         /* This code goes at the top of the generated file.  */
         #include <config.h>
       }

  (b) The generated lexer's .c file may be compiled indirectly, through
      a #include. Say, if flex generated foo-lex.c, the project could
      choose to not compile foo-lex.c but instead foo-token.c where
      foo-token.c is a file that contains
        #include <config.h>
        #include "foo-lex.c"

  (c) The project's Makefile could postprocess the generated .c file,
      adding a '#include <config.h>' right after the
      "/* begin standard C headers. */" line.
      For example, through a Makefile rule that does

        sed -e '/begin standard C headers/a#include <config.h>' < foo-lex.c > 
foo-lex.c.new
        mv foo-lex.c.new foo-lex.c

> IMHO, this is a problem with Flex, not GnuLib.  Flex should have a mechanism
> to insert code at the top of the generated lexer like Bison’s "%code top”
> directive.

As far as I know, it already has.
https://westes.github.io/flex/manual/Definitions-Section.html

> So this is just an FYI that the aforementioned commit can break machine 
> generated C code.

Yes, and the expectation is that fixing this on the projects's side
(that makes use of flex) will avoid hard-to-investigate compilation
errors on various platforms.

Bruno