Re: libfl.a and common code

[John]

> In flex with the reentrant option and multiple lexical analyzers,
> there are multiple functions with different names but identical
> code.  For example, if there are lexical analyzers with prefixes
> a, b, c, ..., there will be multiple functions
> aget_out, bget_out, cget_out, ...
> aset_out, bset_out, cset_out, ...
> alex_init, blex_init, clex_init, ...
> alex_destroy, blex_destroy, c_lex_destroy, ...
> etc., each set having absolutely identical code.
>
> Such duplicate code adds unnecessary bulk to a project and fails
> to take advantage of potentially common code for execution speed
> (e.g. cache hits).  Wouldn't it be better to have a single set of
> functions with the yy prefix and contained in libfl.a?
>
> Of course, where code is not identical, e.g. yy_scan_buffer,
> separate functions are necessary.

Two given functions may appear identical, but they are not.  The
definitions of struct yyguts_t and struct yy_buffer_state may be
different for different scanners. Certain struct members are omitted,
added, or have their types altered, depending upon user options.  The
result is that the byte offset of any given struct member is not the
same in all scanners.

Any function that references a member of a flex-generated struct is
specific to that scanner, and can not be used with other scanners. To
enforce this, I considered putting a magic number field as the first
field in each struct. The serialization mechanism already has a
similar safeguard.

Currently, you can (incorrectly) pass an instance of scanner zz to a
function generated for scanner yy, and flex will not complain -- but
the results are unpredictable.