Re: flex beta 2.5.23 released

[Bruce Lilly]

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

Indeed it does; e.g. K&R declarations.  My implicit point is that
if pre-C99 compatibility is to be abandoned (and therefore K&R
compatibility as well), then there are other things, such as the
K&R declarations, that should be revised; conversely if there is
to be any semblance of portability to pre-C99 systems, use of
C99-specific types isn't going to work.

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

Will do.

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

Unless I'm mistaken, *exact* sizes aren't necessary; what is needed is
assurance that a particular type is sufficiently large to hold some
number (state number, source code line number, etc.).

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

I suspect that part of the problem is the assumption that gcc is always
right, which is not a valid assumption.  Solicitation of tests on non-gcc
systems would probably reveal a number of issues.  In the specific case
under discussion, gcc has the intN_t types defined in the wrong place.