|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
OP
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Somewhere between 6.35 and current, $hfind changed to no longer search past the 'line length limit'. Results from different versions: 1 vs 1 123456791 6.35 /hfind_test 123456789
1 vs 0 4151 7.52 /hfind_test 4149
1 vs 0 8293 7.52 1265 /hfind_test 8291
alias hfind_test {
bset -t &var $1 abc
noop because hfind won't search past 0x00: | breplace &var 0 $asc(a)
hadd -bm table item &var
echo 4 $hfind(table, *b*, 0, w).data vs $hfind(table, *c*, 0, w).data $bvar(&var,0) $version $beta /hfind_test $1
hdel table item
}
Edit: The above was for wildcard match. For regex match, 6.35 couldn't see past the line length limit like it could for wildcard match. (Thanks Wims) For the below, 6.35 matches at %len 4150 but not 4151. In the newest beta, regex's limit is %len 8292 //var %len 4151 | bset -t &var %len b | breplace &var 0 $asc(a) | hadd -bm table item &var | echo 4 $hfind(table, (a*b$), 0, r).data $bvar(&var,0)
Last edited by maroon; 12/10/18 06:40 PM.
|
|
|
|
|
Joined: Dec 2002
Posts: 5,486
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,486 |
Thanks for your bug report. I have been able to reproduce this issue. This is due to a change in the very first Unicode version of mIRC, which required introducing UTF-8/UTF-16 conversions throughout the code. I have updated the next beta so that the 'w' option will allow unlimited string length matching.
However, this cannot be easily changed for regex as the string length limit is something that is imposed throughout the regex routines. Allowing unlimited string lengths in the regex routines would require a significant rewrite. This has been added to my to-do list.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
If this is fixed, how would $regml and $regmlex behave if the regex is capturing a string that is more than 8292 characters? Would they chop at 8292 or would they return a line too long error?
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: Dec 2002
Posts: 5,486
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,486 |
If this is fixed, how would $regml and $regmlex behave if the regex is capturing a string that is more than 8292 characters? Would they chop at 8292 or would they return a line too long error? String length checking is performed in all of the regex routines/identifers/etc. in numerous places. If evaluation reaches the stage of storing results in $regml(), they would be truncated. It may be that different routines will report a line too long error and halt the processing before it reaches that stage. Substitution would also be a problem. There would also be issues with calling commands to evaluate parameters during regex evaluation, where it would be necessary to truncate parameters since script commands and identifiers cannot exceed the maximum string length. And so on. So, while it might be possible to extend regex in some ways to handle matching against longer text, some regex features, such as alias call evaluation of parameters, will never be able to handle it.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
Yes, I agree, I was going to say multiple things but only posted about $regml*.
First of all, I wanted to mention something about the limit, right now we have $maxlenl = 8192, which corresponds to the previous 4096, representing the 'safe' number of character allowed per 'line', shouldn't this number have been used as the limit for $regml* here (but this is also meaningful for others areas)? Which would leave room for handling $regml* value with for example an /echo or whatever, whereas right now, a $regml* value of 8292 characters is very hard to deal with.
I don't think $hfind should be handling match against longer string via hadd -b, because I don't think people expect it to, even the interested scripters: binvar support for regex has been asked in 2003 but nobody really thought of using $hfind to do a match on a binvar, at least I've never heard/seen such things.
For all the reasons you mention, even if it were fixed, it would be far from having binvar support for input of regex, this would just be knowing if there's a match. That's as good as it can be for wildcard though, so maybe just having wildcard not truncating makes sense.
Note that /filter works on long line with regex last time I tried it.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: Dec 2002
Posts: 5,486
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,486 |
First of all, I wanted to mention something about the limit, right now we have $maxlenl = 8192, which corresponds to the previous 4096, representing the 'safe' number of character allowed per 'line', shouldn't this number have been used as the limit for $regml* here (but this is also meaningful for others areas)? Which would leave room for handling $regml* value with for example an /echo or whatever, whereas right now, a $regml* value of 8292 characters is very hard to deal with. The same issue applied to $regml() with 4096, where the longest string could technically have been around 4150. Unfortunately, there is no way to limit all strings to 8192. The maximum string length, with leeway up to 8292, applies to all routine equally. If I did what you are requesting, I would have to arbitrarily choose some routines/identifiers/commands/features to only allow a maxumum of 8192 and others, such as /echo, to allow the leeway up to 8292. That is simply not possible. I would have to make this change, and add checks, in thousands of places for it to make sense. For all the reasons you mention, even if it were fixed, it would be far from having binvar support for input of regex, this would just be knowing if there's a match. I think I have found a safe route through the regex code that allows unlimited string length regex matching. As you say, it will only let you know if there's a match. Results would still be truncated. I may include this change in the next beta.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
Yeah, I wasn't asking for a change, but I was wondering if that was the intended plan. As I explained it would make more sense for us scripters to be able to deal with such a long value. I think I have found a safe route through the regex code that allows unlimited string length regex matching Nice, but are there no plans for real binvar support in regex input?
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
