Re: flex beta 2.5.23 released

[Bruce Lilly]

W. L. Estes wrote:
> 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.

Well, of course it's beta. See the subject header line.  And the only
chance of getting flex to work everywhere is if problems are reported.

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

Go ahead and declare that flex is only for POSIX-compliant systems if
you wish -- that doesn't affect this issue.  POSIX doesn't define the
intN_t types, that is done in the C99 ANSI C extensions.

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.

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.

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

I've clearly stated that the provided mechanism doesn't work. And that
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>.

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

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.