Page 1 of 2

[Solved] Possible bug in Instr or gb.IgnoreCase in Gambas 3.12.0

Posted: Wednesday 2nd January 2019 5:29am
by Godzilla
UPDATE: for those who've ugraded to 3.12.0, this bug is squashed as of the upcoming 3.12.1 stable release. Until then, if your code uses (InStr + gb.IgnoreCase), the (String.InStr + gb.IgnoreCase) or (InStr + LCase ) combinations will allow your code to continue working normally.

------------------------------------------------------------------------

Linux Mint 18.3 on one computer
Linux Mint 19.1 on the other computer
Gambas 3.12.0 on both

I've always used Instr in Gambas and never had an issue with it whatsoever. In the past few days, I've been stumped trying to figure out why my code has suddenly stopped working as expected.

Well, long story short, what worked for me was to replace all instances of InStr in my code with String.InStr. That appears to have solved the problem for me.

I don't know why this happened. I haven't changed any setting regarding character coding on either computer. It could have been the recent Gambas upgrade. Or it could have been some random Linux program update or Linux system update.

In any case, I just wanted to spread the word. If there's anyone else out there suddenly realizing that formerly perfectly-functioning code is now giving strange output, this info might be a big help to you.

I haven't yet replaced every single string manipulation command I use with its "String" function counterpart. InStr was the only one I found that was obviously wreaking havoc for me. But it may be a good idea to replace the rest soon. Here's a list of all the "String" function methods:

Byte
Chr
Code
Comp
InStr
Index
IsValid
LCase
Left
Len
Lower
Mid
Pos
RInStr
Right
UCase
UCaseFirst
Upper

Thanks for reading and I hope this is a help to someone.

Re: Try replacing InStr with String.InStr if code is suddenly acting strange

Posted: Wednesday 2nd January 2019 4:26pm
by cogier
Hi Godzilla,

I have tried various permutations, using Gambas 3.12.0 on Mint 19.1, but I can't find fault with Instr or RInstr.

Have you got a sample of code that worked and doesn't now?

Re: Try replacing InStr with String.InStr if code is suddenly acting strange

Posted: Wednesday 2nd January 2019 5:46pm
by Godzilla
Hi, cogier. Sure.

Code: Select all

Dim TheString As String
TheString = "Gambas is Basic"
Print InStr(TheString, "bas", 0, gb.IgnoreCase)
Print InStr(TheString, "basi", 0, gb.IgnoreCase)
Print String.InStr(TheString, "bas", 0, gb.IgnoreCase)
Print String.InStr(TheString, "basi", 0, gb.IgnoreCase)
Without running the code, I would expect the output of this to be:

Code: Select all

4
11
4
11
But on on both of my computers, with different versions of Linux Mint Mate (one having just recently been low-level formatted with a fresh install of Linux Mint Mate 19.1), the output is:

Code: Select all

4
0
4
11
I don't really understand it. I don't think I'm doing anything wrong in line #4 of the code. Though I've been wrong before and not realized it.

On line #6, the "String.InStr" counterpart of line #4 is giving a different result of 11, which is what I would have expected from line #4 as well, which is instead giving 0.

This sudden irregularity with InStr wreaked havoc on the output of my program, which was working without issue until a few days ago. I started out being completely baffled. But, eventually I was able to trace it down to this InStr issue.

Thanks for your reply, cogier. Please let me know if I'm doing something wrong, or if this is a bug in the new release.

Re: Try replacing InStr with String.InStr if code is suddenly acting strange

Posted: Thursday 3rd January 2019 5:27am
by grayghost4
this is my results
Fedora
XFCE
Gambas 3.11.4

Re: Try replacing InStr with String.InStr if code is suddenly acting strange

Posted: Thursday 3rd January 2019 8:00am
by Godzilla
grayghost4 thank you for your reply and for testing the code. I see its working as expected on your system, as it did on both my computers before upgrading to Gambas 3.12.0.

I had no idea images could be attached to posts here. That will be very useful! I hope this works. I'll be trying to attach one screenshot from each of my computers.

Re: Try replacing InStr with String.InStr if code is suddenly acting strange

Posted: Thursday 3rd January 2019 9:47am
by stevedee
What happens if you replace gb.IgnoreCase with 1

Could you also try replacing "bas" & "basi" with "as" and "asi" while still using IgnoreCase

Re: Try replacing InStr with String.InStr if code is suddenly acting strange

Posted: Thursday 3rd January 2019 2:17pm
by cogier
I have run your code on Mint 19.1 64bit Cinnamon with Gambas 3.12.0 and I get the same problem. The problem seems to be with the 'gb.IgnoreCase' as changing the 'bas' to 'Bas' corrects the problem.

Print InStr(TheString, "Basi", 0, gb.IgnoreCase)   'Correct result
Print InStr(TheString, "basi", 0, gb.IgnoreCase)   'Wrong result
Print InStr(LCase(TheString), "basi")              'Correct result

I have tried it with gb.gui, gb.gtk3, gb.qt4 and gb.qt5 and they all produce the same results.
I can confirm that like grayghost4 using Fedora 29 and Gambas 3.11.4 all is OK. I will try to update Fedora with 3.12.0 and report back. (EDIT: To many errors trying to compile it :cry: )

Re: Try replacing InStr with String.InStr if code is suddenly acting strange

Posted: Thursday 3rd January 2019 2:54pm
by stevedee
cogier wrote: Thursday 3rd January 2019 2:17pm ... The problem seems to be with the 'gb.IgnoreCase' as...

Well it could be with gb.IgnoreCase or with Instr, hence my suggested tests above.

i.e. does gb.IgnoreCase still equate to 1 on 3.12.x?

Re: Try replacing InStr with String.InStr if code is suddenly acting strange

Posted: Thursday 3rd January 2019 4:22pm
by cogier
i.e. does gb.IgnoreCase still equate to 1 on 3.12.x?
My tests indicate that it does

The following code shows that gb.IgnoreCase still works
Public Sub Form_Open()
Dim sToSort As String[] = ["A", "c", "B", "b", "a", "C"]
Dim sIgnoreCase As New String[]

sIgnoreCase = sTosort.Copy()
sIgnoreCase.Sort(gb.IgnoreCase)

sToSort.Sort()

Print sToSort.Join(" ") & "  Case not ignored"
Print sIgnoreCase.Join(" ") & "  Case ignored"

End
The result: -
A B C a b c Case not ignored
A a B b c C Case ignored

I have tested Godzilla's code on Mint 19.1 with Gambas 3.11.4 and it works as expected.

If you are not using Mint or Ubuntu and you are using Gambas 3.12.0 can you let us know if the problem occurs on your system.

Re: Try replacing InStr with String.InStr if code is suddenly acting strange

Posted: Thursday 3rd January 2019 5:55pm
by Godzilla
cogier and stevedee, thank you both for being on this.

cogier thank you for reproducing the problem and confirming that this isn't an issue specific to my computers. And thank you for trying to compile 3.12.0 on Fedora. Looking over the complex compile instructions for Gambas, its something I would not even dare attempt.

stevedee, I can confirm what cogier wrote, that gb.IgnoreCase still appears to be 1. Replacing gb.IgnoreCase with 1, the output is the same (4 0 4 11).

While pinpointing the exact reason for this error will have to be one for the experts (which I am certainly not), I can do a bit of sleuthing. I asked myself: why does String.InStr work as expected, while InStr does not? What is the difference in these two functions?

According to the Gambas documentation, the difference is the character encoding they're designed for.

"InStr only deals with ASCII strings. To manipulate UTF-8 strings, use the String class"

Ok, does this mean the String class only deals with UTF-8? The documentation doesn't specifically say so. But this tidbit from the String function documentation seems to indicate it does. "To use a non-UTF8 string you must first convert it with Conv$."

The next question is: what is a main difference between 3.12.0 and 3.11.4? Well, one difference is 3.12.0 uses the JIT compiler. So, could it be that the default character encoding for the JIT compiler is UTF-8? I was not able to determine this definitively with my research. But if its true, would it explain why String.InStr works for the code in question, while InStr does not?

I can also confirm this bugged output (4 0 4 11) exists also on the current Gambas-Daily development version of 3.12.0, running in the latest Ubuntu Mate in a virtual machine (VirtualBox).

DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"
NAME="Ubuntu"
VERSION="18.04.1 LTS (Bionic Beaver)"

Thanks for reading.