Re: flex beta 2.5.23 released

[W. L. Estes]

On Monday, 25 November 2002,09:40 -0500, Bruce Lilly wrote:

> That would still be a problem as flex would then
> *require* the C99 extensions to ANSI C.  It would
> be completely incompatible with K&R C.

Careful, Bruce. We're going for ANSI compliance. K&R C is not our
goal--although flex has some K&R code in it, if memory serves.

> Look at what the FLEX_NEEDS... branch does (ignoring int64_t):

There are some changes in the flexint.h header in flex beta
2.5.24. Could you have a look at it and tell us how it works for you?

> typedef signed char int8_t;
> typedef short int int16_t;
> typedef int int32_t;
> 
> One might as well simply *use* signed char, short, and int
> types (since that will be exactly the same as when the
> FLEX_NEEDS... branch is taken) and avoid the portability
> issues.  And before you reply that short isn't necessarily
> large enough for 16 bits, note that in those cases the
> FLEX_NEEDS... branch won't work anyway.

We've thought about defining our own types. It's really a matter of
where and how we want our headaches. We would probably still want
types that explicitly say how big they should be because it will help
in the programming of flex. E.g. flex_int32_t. That solution would
require some recoding, but hopefully it could be done easily. All this
is still open, of course. The real issue that we're dealing with is
the varying degrees to which systems conform to various
standards. flex is trying to find a happy medium and is succeeding to
a certain extent. The systems where flex does not quite succeed in its
latest beta incarnations present very odd problems. We're trying to
figure them out. The more helpful and detailed problem reports that we
get, the more we can do.

--Will