View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000878LDMud 3.6Efunspublic2020-05-06 23:442020-09-01 22:38
Reporterrealms-mud Assigned ToGnomi  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformx64OSSolarisOS Version11.4.20.4.0
Product Version3.6.2 
Fixed in Version3.6.3 
Summary0000878: Regular Expressions somewhat broken with 3.6.2
DescriptionWhen switching from the 3.6.1 driver to the 3.6.2 driver, I noticed that several hundred regular expression-based checks in my tests no longer work. There are work-arounds for most and I'll even agree that some of the workarounds are "more elegant" and/or "better", but previously-working valid syntax should still be honored. Both regexp and regreplace are affected.

In the "steps to reproduce", I'll give a few examples.
Steps To ReproduceFor simplicity, consider the following method to evaluate whether or not a regexp matches a passed string:

/////////////////////////////////////////////////////////////////////////////
public void ExpectSubStringMatch(string regularExpression, string evaluatedString)
{
    if (!sizeof(regexp(({ evaluatedString}), regularExpression)))
    {
        debug_message(" -> Actual: " + evaluatedString+ ", Expected: " + regularExpression+ "\n",
            0x5);
    }
}

Here's a few that fail with the changes that were made in 3.6.2:

    ExpectSubStringMatch("Optional.*Leather needed.*1.*Metal needed.*10",
        "This option lets you craft: long sword\n"
        "Prerequisites:\n"
        " Skill: Blacksmithing of 1\n"
        " Research: Craft Long Swords\n"
        " Skill: Weapon smithing of 8\n"
        " Skill: Metal crafting of 1\n"
        "\n"
        "Materials:\n"
        " (Optional) Crystal can be used to embellish the design\n"
        " Leather needed: 1\n"
        " Metal needed: 10\n"
        " Wood needed: 1\n");

    ExpectSubStringMatch("Blah blah blah.*This item contains the following.*.3. Long sword",
        "Blah blah blah\nThis item is typical for its type.\n\n"
        "+-=-=-=-=-=-=-=-=-=-=-+ This item contains the following +=-=-=-=-=-=-=-=-=-=-+\n"
        "| Battle axe Healing Potion [3] Long sword |\n"
        "| Mana Potion Short sword |\n"
        "+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+");
-> Digging further, it looks like two wildcards in a row don't work any longer (ie: the '.*.' was the culprit here. Likewise, in another test, '..' did not evaluate correctly)

    ExpectSubStringMatch("Dracolich Form.*[*].*Dragon",
        "Dracolich Form (*) [12] - Dragon Form");
-> With this, it doesn't appear to like the [*]. "Dracolich Form.*\\*.*Dragon" evaluates. Interestingly, so does "Dracolich Form[^*]+\\*.*Dragon" (ie: not-in-set succeeds, but in-set does not in this case)
TagsNo tags attached.

Activities

Gnomi

2020-05-07 02:37

manager   ~0002531

Thank you for catching that. The regexp matching functions communicate mostly via global variables and I overlooked some side effect of that.

A fix is in my branch: https://github.com/amotzkau/ldmud/tree/363preparations

realms-mud

2020-05-07 18:08

reporter   ~0002532

Thanks for the super-fast response!

I ran your fix through my test suite and everything is working as expected.

Issue History

Date Modified Username Field Change
2020-05-06 23:44 realms-mud New Issue
2020-05-07 02:37 Gnomi Note Added: 0002531
2020-05-07 02:37 Gnomi Assigned To => Gnomi
2020-05-07 02:37 Gnomi Status new => confirmed
2020-05-07 02:37 Gnomi Status confirmed => assigned
2020-05-07 18:08 realms-mud Note Added: 0002532
2020-09-01 22:38 Gnomi Status assigned => resolved
2020-09-01 22:38 Gnomi Resolution open => fixed
2020-09-01 22:38 Gnomi Fixed in Version => 3.6.3