Re: flex beta 2.5.22 released

[Bruce Lilly]

W. L. Estes wrote:
> On Friday, 11 October 2002,01:03 -0400, Bruce Lilly wrote:
>
>
> > W. L. Estes wrote:
> >
> >
> > > ** more portability fixes around how we get ahold of the integral
> > >  types; there is a constant FLEX_NEED_INTEGRAL_TYPE_DEFINITIONS
> >
> > [...]
> >
> > That's an improvement, but the choice of types used is rather
> > puzzling.  The only int[0-9]+_t used is int32_t... it would
> > have been simpler in that case to just use a plain int and
> > avoid all of the hassle.
>
>
> Not so. there are a few int8 and int16 references scattered here and
> there. And we're trying to guarantee the size of the ints we use. so
> just "int" is not sufficient.

I didn't see any in the test case I used, which is a fairly
complex lexical analyzer.  But some (e.g. the line numbers)
were clearly overkill.

> Bruce, can you confirm for me that you're able to build flex and
> scanners it generates? (I know you had troubles with 2.15.21 so I'd
> like to be sure you're ok on this point.)

Yes, on two platforms tested; I haven't tried the third yet.

> > Some uses are really odd: for example in a rather complex
> > lexical analyzer, I get:
> >
> > static yyconst int32_t yy_rule_linenum[83] =
> >    {   0,
> >      213,  239,  264,  289,  298,  319,  330,  338,  349,  357,
> >      367,  377,  387,  422,  434,  449,  460,  470,  478,  488,
> >      496,  504,  512,  520,  528,  537,  545,  553,  561,  570,
> >      578,  586,  597,  606,  616,  625,  639,  648,  658,  666,
> >      677,  689,  698,  709,  718,  727,  737,  748,  783,  815,
> >      836,  844,  853,  861,  871,  882,  893,  902,  911,  919,
> >      934,  942,  957,  965,  973,  981,  989,  997, 1005, 1013,
> >     1029, 1039, 1047, 1056, 1065, 1075, 1086, 1108, 1118, 1127,
> >     1136, 1145
> >    } ;
> >
> > Line numbers are always nonnegative, so an unsigned type
> > would be more appropriate.  Also, as the maximum value in
> > this case is well under 65535, a uint16_t could have been
> > used, halving the memory used for the table.
>
>
> John, could you comment on this?
>
> Bruce, I don't know how big the numbers get so it might be that in
> most cases 16 bits is ok but in a few cases 16 bits is not enough.

Well, a source .l file with more than 65535 lines is a HUGE
lexical analyzer (or an error).  I'd expect many simple ones
might have 255 lines or less.