[MERGE] scan_data_t: make fixed/float data array
authorDavid Mitchell <davem@iabyn.com>
Sun, 2 Jul 2017 20:25:35 +0000 (21:25 +0100)
committerDavid Mitchell <davem@iabyn.com>
Sun, 2 Jul 2017 20:25:35 +0000 (21:25 +0100)
commit6efb583a3779086d6dce2899767ca920f0eda754
treec00397782f697a182947f27b4146e96ec6a0240b
parentb9a58d500dd75ba783abac92a56e57d41227f62b
parent37b6262ff693a05099d6f0ccc01328e5223f6a85
[MERGE] scan_data_t: make fixed/float data array

While compiling a pattern, rather than storing information about the
current longest fixed and floating substring as individual fields of this
struct - such as minlen_fixed, minlen_float etc - create a 2-element array
to hold fixed and float data. So for example

    data->lookbehind_float

becomes

    data->substrs[1].lookbehind

etc.

This mimics the way that substring data is stored in the regex struct
once the pattern has been compiled.

Similarly, move some fixed/float-specific flags from data->flags
into a new per-substr subfield, data->subfield[i].flags.

Also, the fixed substring now has both max and min offset fields, which
are set equal to each other.

This set of commits should make no functional difference apart from
minor changes to debugging output (e.g. fixed offsets displayed as N..N
rather than N).

The various commits in this branch are mainly concerned with harmonising
fixed and float code paths, and finally parameterising them, e.g.

    data->lookbehind_fixed = ...;
    data->lookbehind_float = ...;

becomes

    data->substr[0].lookbehind = ...;
    data->substr[1].lookbehind = ...;

and finally becomes

    for (i = 0; i < 2; i++) {
        data->substr[i].lookbehind = ...;
    }

The two big advantages of this approach are;

1) it simplifies and rationalises the code, avoiding two similar blocks of
code in several places;
2) it may allow for future expansion where there isn't necessarily at most
1 fixed and 1 floating substring.

Note that this only affects the regex compile-time code. The run-time
code in re_intuit_start is still a mess and could benefit from a similar
rationalisation (it already has the arrray[2], but doesn't do much
parameterising).