Re: flex beta 2.5.22 released

[Bruce Lilly]

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.

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.

> ** flex tries its best to output only the relevant portions of the
>    skeleton when generating a scanner, thus avoiding as much
>    conditional compilation as possible

Good.  But with %option header, the generated header need
not include <errno.h>, <string.h>, or <stdlib.h> as there's
nothing in that header file which needs any of those.