GnuLib update renders Flex lexers uncompilable

[paul-j-lucas]

This recent commit in GnuLib 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.

AFAIK, there's no way to request that Flex insert code at the very beginning of a file like %code top in Bison.

So how can this be fixed?

[paul-j-lucas]

Of course an obvious work-around is to add -D_GL_CONFIG_H_INCLUDED to CFLAGS, but then that defeats the purpose of the check.

[westes]

For planning purposes, what is the update cycle for gnulib users? That is, how quickly is this going to effect folks?

[paul-j-lucas]

I have no idea. I'm just a GnuLib user. If you look at GnuLib's git log, the project seems pretty active. AFAIK, there aren't "releases"; developers just push to the master branch and users (like me) just git pull occasionally.

[westes]

Ah, so one day a gnulib user will be able to compile flex generated lexers, then "suddenly" / "randomly" upon "git pull" from gnulib, they won't. and "occasionally" could mean a lot of things depending on what a gnulib user happpens to need; that is helpful to know, thank you!

[paul-j-lucas]

Actually, I think I misread your question. I thought you asked what the release cycle of GnuLib itself, i.e., how often do the GnuLib developers release a new version of GnuLib.

I have no idea what other GnuLib users do, but I, as a GnuLib user, only tend to update GnuLib right before I'm about to release a new release of my software that uses GnuLib just so it has the latest and greatest, though there generally isn't any other compelling reason since my project's current snapshot works as-is.

[westes]

Thanks -- it turns out I should have asked both questions.

[paul-j-lucas]

If you're using Autotools, another work-around is to augment the generated lexer on-the-fly to #include "config.h" by using a custom Makefile.am rule to make the lexer rather than let Autotools use ylwrap:

# ...

BUILT_SOURCES = parser.c parser.h lexer.c

lexer.c: lexer.l
        { echo '#include "config.h"'; flex $(AM_LFLAGS) -t lexer.l; } > lexer.c

# ...

[bhaible]

Gnulib's answer is here: https://lists.gnu.org/archive/html/bug-gnulib/2023-04/msg00094.html In particular, the workaround/fix (a) is very easy to put in place, and already used by several GNU packages.

[paul-j-lucas]

Apparently, I missed the fact that Flex does have an equivalent to Bison's %code top. In Flex, it's just %top:

%top {
#include "config.h"
}

So I guess never mind.

[Mightyjo]

Thank goodness! I was pretty worried to think %top was broken. Glad it worked out!

On Thu, Apr 13, 2023, 14:37 Paul J. Lucas @.***> wrote:

Apparently, I missed the fact that Flex does have an equivalent to Bison's %code top. In Flex, it's just %top:

%top {

include "config.h"

}

So I guess never mind.

— Reply to this email directly, view it on GitHub https://github.com/westes/flex/issues/564#issuecomment-1507446845, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVJXIIQ3A2ER57RWXFDI3TXBBBYFANCNFSM6AAAAAAW5BEMEU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[bhaible]

there aren't "releases"; developers just push to the master branch and users (like me) just git pull occasionally.

In Gnulib, there are no releases. But there are stable branches: https://www.gnu.org/software/gnulib/manual/html_node/Stable-Branches.html