|
|
Joined: Feb 2003
Posts: 42
Ameglian cow
|
OP
Ameglian cow
Joined: Feb 2003
Posts: 42 |
Discovered an issue with $bfind this morning. Seems that when you specify ascii values for it that it ignores the last one. Hence, if you specify 2 values, it'll match on 1, 3 values, and it'll match on 2. Here's some code for you to play with... alias btest {
bset &debug 1 49 50 48 56 53 57 48 13 10 49 50 48 56 53 57 49 13 10 49 50 48 56 53 57 50 13
var %cnt, %bin.ptr, %text
%bin.ptr = $bfind(&debug, 1, 13 10)
while (%bin.ptr) {
echo -ea b: $bvar(&debug,1,$bvar(&debug,0)) | echo -ea p: %bin.ptr
%text = $bvar(&debug,1,$calc(%bin.ptr - 1)).text
inc %bin.ptr 2 | %cnt = $bvar(&debug,0)
if (%cnt > %bin.ptr) { bcopy -c &debug 1 &debug %bin.ptr $calc(%cnt - %bin.ptr + 1) }
else { bunset &debug }
%bin.ptr = $bfind(&debug, 1, 13 10)
}
echo -ea b: $bvar(&debug,1,$bvar(&debug,0)) | echo -ea p: %bin.ptr
}Here we have 3 numbers, 1208590, 1208591 & 1208592 delimited by a CRLF (13 10) excepting that the last number doesn't have it's LF, only the CR. You'll note that mIRC happy $bfinds it anyway. alias btest2 {
bset &debug 1 49 50 48 56 53 57 48 87 65 86 49 50 48 56 53 57 49 87 65 86 49 50 48 56 53 57 50 87 65
var %cnt, %bin.ptr, %text
%bin.ptr = $bfind(&debug, 1, 87 65 86)
while (%bin.ptr) {
echo -ea b: $bvar(&debug,1,$bvar(&debug,0)) | echo -ea p: %bin.ptr
%text = $bvar(&debug,1,$calc(%bin.ptr - 1)).text
inc %bin.ptr 3 | %cnt = $bvar(&debug,0)
if (%cnt > %bin.ptr) {
bcopy -c &debug 1 &debug %bin.ptr $calc(%cnt - %bin.ptr + 1)
}
else { bunset &debug }
%bin.ptr = $bfind(&debug, 1, 87 65 86)
}
echo -ea b: $bvar(&debug,1,$bvar(&debug,0)) | echo -ea p: %bin.ptr
}Here we changed it around a bit. Instead of using CRLF, we went according to the mIRC help file, which states: $bfind(&binvar, N, M)
Searches a &binvar for a matching value, starting from position N. M can be a character value, ie. 0 to 255, or text. The search is case-insensitive.
$bfind(&test, 1, 87 65 86) finds WAV from pos 1 So in other words, we've delimited the numbers by WAV only here again, with this last number it trails in WA only, missing the V, yet mIRC still bfinds a match. If you trail it with only W it doesn't find the match, has to be all of the characters excepting the last one. Not really an earth shattering bug, but a bug none the less, one that killed a few hours of my time debugging it. Cheers, GregMo
|
|
|
|
|
Joined: Feb 2003
Posts: 42
Ameglian cow
|
|
OP
Ameglian cow
Joined: Feb 2003
Posts: 42 |
Sighs.... Don't suppose anyone cared enough about this one to even comment on it :-/
That aside, Khaled might want to go over the $bfind code closely. Just this morning had an instance where it returned a match at byte 278 of a 277 byte variable. I'm able to repeat it over and over again, within the confines of the variables provided by the remote server, but trying to water down the code to give an example here is beyond the scope of what I'm wanting to put into it (and evidently, any one else that's read this thread).
GregMo
|
|
|
|
|
Joined: Feb 2003
Posts: 7
Nutrimatic drinks dispenser
|
|
Nutrimatic drinks dispenser
Joined: Feb 2003
Posts: 7 |
I also noticed this. Thanks for confirming. Oh and it has cost me hours of useless "find the non-existing bug" debugging too! Khaled please fix this, thanks 
|
|
|
|
|
Joined: Feb 2003
Posts: 42
Ameglian cow
|
|
OP
Ameglian cow
Joined: Feb 2003
Posts: 42 |
heh, no doubt. I bet in the end I spent the better part of 10 hours fooling around with this bug. In the end, I finally gave up on the project. I hope some day to resume it, but I'm leaning more towards exporting as much of it as I can into DLL calls now that I've got mIRC playing nicely with home brewed DLLs :-)
Cheers,
GregMo
|
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
Hmm, I couldn't really figure out what you were refering to ("ignores the last one") till I paid closer attention to the string you were inputting.
I guess a better way of stating this bug might be:
$bfind returns a false match if it reaches the end of the variable while in a partial match, and it's only one character away from completing the match.
However, I cannot seem to reproduce this error in my own coding. Please use an example similar to these, using only /bset and $bfind to demonstrate this error.
//bset -t &binvar 1 ABCD | echo -a $bfind(&binvar,1,CDE)
//bset -t &binvar 1 ABCDEABCD | echo -a $bfind(&binvar,4,CDE)
//bset &binvar 1 65 66 67 68 | echo -a $bfind(&binvar,1,67 68 69)
//bset &binvar 1 65 66 67 68 69 65 66 67 68 | echo -a $bfind(&binvar,4,67 68 69)
The above two sets of examples are identical, except that specifying plain-text in $bfind is NOT case-sensitive. The above examples return the expected results of 0 (no match).
- Raccoon
Well. At least I won lunch.
Good philosophy, see good in bad, I like!
|
|
|
|
|
Joined: Feb 2003
Posts: 7
Nutrimatic drinks dispenser
|
|
Nutrimatic drinks dispenser
Joined: Feb 2003
Posts: 7 |
Ok, since I also had some problems with false results returned by $bfind, I was playing around to find a way to make my script work... I'm still not completely sure what causes the bug to happen, but I'm pretty sure it has something to do with "/bcopy -c". The bug only seems to be reproducable when you've done a /bcopy -c on the binvar which decreases it's length. So here's my theory: /bcopy [-zc] <&binvar> <N> <&binvar> <S> <M>
This copies M bytes from position S in the second &binvar to the first &binvar at position N. This can also be used to copy overlapping parts of a &binvar to itself.
If you specify the -c switch, the first &binvar is chopped to length N + M. The above quote is from the mirc help. It says the binvar gets chopped to length N + M, which doesn't make much sense. If you think about it, you will come to the conclusing that the binvar should be chopped to the lenght N + M - 1, because the first position in a binvar is not 0, but 1. So I guess there's no bug in $bfind, but a logical misconception in the way /bcopy -c works. Using /bcopy -c on a binvar will return a binvar which is one byte longer than expected (if it gets chopped that is). That would explain why $bfind finds the whole match when reaching the "end" of a binvar, which isn't really the end. Sorry for my bad english, I hope my explanations made sense
|
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
Actually...
The first character in a &binvar is 1.
The first character in a file is 0.
To /bset|&bfind...etc from the beginning, you specify 1.
To /bread from the beginning of a file, you specify 0.
I still can't reproduce the error as described.
- Raccoon
Well. At least I won lunch.
Good philosophy, see good in bad, I like!
|
|
|
|
|
