#915 SysFileSearch not returning hit

[robn]

I'm running OORexx Windows 32bit 4.0.1 (tried 4.0.0 too)
I have a haystack file with lots of strings in. At column 4226 of my file, I have:

E,56551210A 770 5

My code runs:
..
CALL SysFileSearch needle, data, stem
NEEDLE => "56551210A 770"
"56551210A 770"
DATA => "haystack.txt"
"haystack.txt"
STEM => "STEM"
"STEM"
"0"

if stem.0=0
STEM.0 => "STEM.0"
STEM.0 => "0"
"0"
"=" => "1"
"1"

so it is not seeing the entry which is there.

If I 'grep' the file and check the rc, it works fine - but it much slower.
Is this a bug, or a restriction on line length?

Thanks.

[Mark Miesfeld]

If you would provide both the data file and an example program that demonstrates the problem, you are likely to get a developer to take a look at this.

For example, this is the third time I've looked at it, but decided to skip it because I don't have the time to try and create a data file and test case from the little information you have provided. What does it mean "a lot of strings?" How long are strings? etc..

[Mark Miesfeld]

Fix bug title

[Mark Miesfeld]

Changing priority because the submitter has failed to provide an example program.

[Jerry Senowitz]

Ran into this problem in 4.2.0 using Windows XP SP3 (32 bit). It appears that SysFileSearch will not find lines where the search argument is in columns greater than 4095 bytes. If the search argument is found in columns 1-4095? it will only return 4096 (with the "N" option) bytes of the line where a match was found even though the line is longer.

Here is a self contained test to demonstrate the problem (nothing fancy):
fn = "test"
ln = ""
do i=1 while length(ln) < 4096
ln = ln i
end
call SysFileDelete fn
call lineout fn,ln
call lineout fn
rc = SysFileSearch(i-1,fn,"fl")
if rc \= 0 then say "File Problem:" rc
else say fl.1
call SysFileDelete fn

If you change the 4096 to 4090, it works fine!

If you prefer, I can open up a new problem on this. Let me know.

[Erich]

Documenting this as a restriction with [r11293].

[Erich]

Jerry, I'm not happy with [patches:#197], which just moves the restriction from 4K to 64K
Would you like to provide a SysFileSearch patch for the current 5.0 trunk, that removes the restriction, i. e. use the default 4K buffer if a line fits, allocate and re-allocate ever larger buffers otherwise?

We'll always need to patch both Windows and Unix .. please also provide a Unix patch (preferably, the Unix code should be identical or as close as possible to the Windows code).
I'll do any final fixes and tests on Unix, as I understand you can't compile/test for Unix.

---

Hi Erich,

Got a notification a few minutes ago about #915 and it will be a restriction. Back in 10/2015 (see patches #197) I proposed a simple fix for bug 915 if you are interested, as well as several other problems I had encountered. The solution is documented in patches2.zip (patches.txt). It was one of my first attempts at modifying oorexx. Have been running with all the fixes in that patch for ~2 yrs now with no ill effects. This includes Windows XP(32 bit) & 7(64 bit).

The ultimate implementation decision, though, rests with oorexx development team.

Jerry

---

[Rick McGuire]

This should be fixed in the latest 5.0.0 trunk.