Re: flex beta 2.5.23 released

[Bruce Lilly]

W. L. Estes wrote:

> scan.c and skel.c are both automatically generated so patching them
> won't help in the long run.  We can't just include inttypes.h because
> not everyone has it.

<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!).

> 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.

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.