Re: flex beta 2.5.23 released

[W. L. Estes]

On Saturday, 23 November 2002,17:28 -0500, Bruce Lilly wrote:

> As distributed, flex 2.5.23 doesn't work w/o the macro (because
> the appropriate header is not included) or with the macro (because
> of a syntax error in the path taken by the preprocessor when the
> macro is defined).  So after all of the contortions, flex still

Isn't that last problem a problem with your C preprocessor?

> doesn't build as distributed on some ANSI- and POSIX-compliant
> systems.

Name them. Send us output from the configure/make runs. We'll see what
we can do. But now, we have no information on what the problem is or
where it happens, so we can't fix it.

> The current stable release of flex, 2.5.4a, does not have this problem. It
> generates .c files which are quite portable.

Bruce, that's obvious. That's why the flex 2.5.23 and friends are beta
releases. We're trying to get flex development done. We need to be
able to add functionality and figure out how to get it working
everywhere. If you want the stable release of flex, then use it, by
all means. If you want to use the beta releases of flex, go for it. We
like having the input on how we're doing, but the price you pay is
that you are going to have problems.

> >The problem is identifying whether or not the given <inttypes.h> is a
> >*working* one. It seems that some systems have the file, but the
> >contents violate the standard.

Yes, this bit me hard, at least once. John Millaway and I have beaten
our heads against this wall a lot. We'd love a good solution to this problem.

> The *root* problem is that the intN_t types are inherently non-portable:
> * they are optional, even in C99, which means that there are ANSI-compliant
>   systems that don't define them
> * they *may* be defined (in <stdint.h>, included via <inttypes.h> per C99),
>   in which case there may be a conflict with alternate attempts to
>   define the same type
> * there are similar issues with "long long" and "long long" vs. "long long 
> int",
>   so even in the absence of a system-supplied type definition, there is no
>   portable way to get an int64_t as a basic type (as opposed to a 
>   structure).
>   [though it's unlikely that any practical lexical analyzer would require
>   tables so large]

and no one will ever need more than 640K RAM.

Can someone post a confirmation that the int*_t types are optional? If
that's the case, then we have a very different problem on our
hands. (Section numbers from the C99 standard or quotations or urls so
we can all check up on it.)