Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False-positive regex-detection and code improvement suggestion #146

Open
Lab5-Switzerland opened this issue Dec 11, 2023 · 0 comments
Open

Comments

@Lab5-Switzerland
Copy link

Lab5-Switzerland commented Dec 11, 2023

False-positive regex-detection and code improvement :

The issue is that in the the following JS code a regex is detected, which really isn't one after all.
Solution : No need to overreact and throw an exception and break and the script ! -> just let it run and accept that some minor part of JS stays uncompressed, but at least the overall script/application can run smoothly, which is of much higher priority!

Let me explain : I had this part of JS script :

case 'f':
subst = (precision > -1)
? Math.round(parseFloat(param) * Math.pow(10, precision))
/ Math.pow(10, precision)
: parseFloat(param);
break;
case 'o':

You see that division operator at the beginning of the line ?
This is what JShrink detects as the beginning of a Regex, thou it isn't.

My simple solution was to change the function saveRegex() a little :
Instead of : throw new \RuntimeException('Unclosed regex pattern at position: ' . $this->index);
just let the loop within saveRegex() end here smoothly !

here my changed code - see my comment there and excuse my probably suboptimal english, but i hope you'll catch my drift, so to speak :

// ORG :
// throw new \RuntimeException('Unclosed regex pattern at position: ' . $this->index);

// NEW :
/* * *
Lab5 : Just stop and chill.
Does not necessarily mean we have a broken, regex; Could just mean it wasn't a regex after all.
For example: a simple Devision-Operator can falsely be detected as a regex-begin if it stands as first char in a new line, but it isn't, it's just a line/part of a calculation expression.
So we will simply end this here, no need to overreact. Should have no negative consequences, it's just that the last, tiny part since the begining of the falsely detected/assumed regex, hasn't gotten compressed. But that's a very small price to pay for an overall running code :)
* * */
break;

Cheers m8
and thanks a bunch for that ultra usefull piece of code that JShrink represents!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant