Re: flex beta 2.5.23 released

[W. L. Estes]

On Monday, 25 November 2002,10:13 -0500, Bruce Lilly wrote:

> And please note that the issue is not a header file problem *here*; the
> provided patch works by including the header file specifically mentioned
> by the relevant ANSI C standard, viz. <inttypes.h>.  And I intentionally
> did not remove the #include directive for <sys/types.h> so that flex
> could still be built on broken systems that incorrectly put intN_t typedefs
> there instead of in the correct header.

I've seen more systems get the integer types by including sys/types.h
than with inttypes.h. I've tried a number of schemes to make this
happen already. Believe it or not, the current one (as in flex 2.5.24)
is the best. It's far from ideal, but most systems aren't compliant to
any given standard.

> What you really seem to want to say is that you intend flex to be
> built and the .c files which it produces to be compiled only by gcc,
> which is quite a different kettle of fish.  Merely because gcc incorrectly
> put intN_t typedefs in <sys/types.h> instead of in the ANSI-specified
> header is no reason to assume that other compilers are distributed with
> the same error.

gcc does not provide the sys/types.h header file. that is provided by
the system's C library.

> I've clearly stated that the provided mechanism doesn't work. And that

Please list the platforms on which flex will not compile. Please send
any configure output and such that will help us understand the nature
of those systems.

> others have also pointed that out.  I've given the details (viz. w/o 
> FLEX_NEEDS...
> intN_t types aren't defined because the appropriate header isn't included,
> and with it there is a syntax error in the line
> typedef long long int int64_t;
> ).  Moreover, I've pointed out that the mechanism may well conflict with
> use of <inttypes.h>.

Have you tried flex 2.5.24?

> Agreed that would be a very bad idea.  But that's essentially what has
> been done, since *some* mechanism to determine whether or not to compile
> the flex-generated .c file with or w/o FLEX_NEEDS... will have to be used
> on each system on which that file will be compiled -- it that mechanism
> isn't exactly autoconf, it will be something equivalent.

No. people compiling flex will have to manually add the -D
option. That's simple and hardly as complex as autoconf. I'd love it
if it weren't necessary to include any mechanism to account for this,
but it is. It's only necessary to pass the switch when building
flex. once flex is built, flex does what it was told to do for your system.

--Will