Re: flex beta 2.5.23 released

[W. L. Estes]

Before responding to particular points, I'd like to remind everyone
that flex 2.5.23 is beta. I've said that all along and I'll keep
saying it until flex reaches an official release. Don't forget it
folks, beta software is not for the squeamish. We're DOING our best to
get flex workable everywhere, but it's a long, hard process.

On Saturday, 23 November 2002,13:11 -0500, Bruce Lilly wrote:

> <stdint.h>, included by <inttypes.h>, (not <sys/types.h>) is where the C99
> version of ANSI C says the relevant optional (N.B.) types (int32_t, etc.)
> are defined.  It's true that some systems might not have it, but that's
> also true of <sys/types.h> (which, unlike <inttypes.h>, isn't even
> mentioned in ANSI C!).

If this sort of thing keeps up, I'm going to declare that flex is only
intended for POSIX-compliant systems. I've gotten flex to compile and
run successfully on a couple flavors of Linux, one version of Solaris
and one version of OpenBSD. I've had success reports for some obscure
flavors of HP-UX as well. If your MS Windows (R) system is broken,
complain to the vendor. If you don't want to use a real unix variant,
that's your choice and I'm glad to help--as long as it's
reasonable. But, if you have a problem in your C header files, that is
not a flex problem. That is a vendor problem--and you should demand
that your vendor fix it. I've tried a number of schemes to get flex to
do the right thing on systems which decidedly refuse to do the right
thing--and it's hard. When you report about platforms that have
problems compiling flex, always list the system you're working on. I
can do *nothing* if I don't know that much.

> > Note the FLEX_NEEDS_INTEGRAL_TYPES constant.
> 
> As noted by others, that doesn't work, since
> typedef long long int int64_t;
> is a syntax error, at least for some compilers.  Moreover, there's no
> convenient way to define FLEX_NEEDS...... when building flex; configure
> doesn't do it, and Makefile is generated by configure.  And there's no
> mechanism to provide for it in cases where the generated .c file is
> compiled on a different system from the one that ran flex to produce
> that .c file.  Also note that on systems *with* a working <inttypes.h>,
> that header should be used rather than the definitions in the
> FLEX_NEEDS........ branch, as the latter may conflict with <inttypes.h>,
> and <inttypes.h> might be included for use with user-defined functions
> in the last section of the .l file.

As millaway noted, pass the -D option on the configure commandline. if
that's too hard, too bad. That's how things are supposed to work in
the autoconf/automake world. Your choice is either use the provided
mechanisms or not to use them. If you don't like them, get over it. If
your claim is that the provided mechanisms don't work, please give us
enough details so that we can fix the problem. We want the provided
mechanisms to work, that's why we put them in the codebase.

Also, it's very hard to tell if a working inttypes.h header file is
present short of forcing people to use autoconf with flex and I think
that would be a very bad idea.

> One way of dealing with the issue would be to distribute a stub
> inttypes.h file with flex that provides a syntactically-valid equivalent
> of the FLEX_NEEDS.......... branch for use on systems that don't have
> the ANSI C header.  The stub header could be distributed with the .c
> file for use when compiling on older systems.  With suitable -I
> compilation flags, that will work on systems whether or not there is a
> standard vendor-supplied <inttypes.h>, including when building flex itself,
> without having to define special-purpose, verbosely-named macros which are
> ignored by configure and make.

We've already thought of this and we try it to a certain
extent. Please see my notes about how autoconf/automake build
systems work.