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

Post your Gambas programming questions here.
User avatar
Godzilla
Posts: 63
Joined: Wednesday 26th September 2018 11:20am

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

Post 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.
Last edited by Godzilla on Saturday 5th January 2019 8:42am, edited 1 time in total.
User avatar
cogier
Site Admin
Posts: 1118
Joined: Wednesday 21st September 2016 2:22pm
Location: Guernsey, Channel Islands

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

Post 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?
User avatar
Godzilla
Posts: 63
Joined: Wednesday 26th September 2018 11:20am

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

Post 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.
User avatar
grayghost4
Posts: 174
Joined: Wednesday 5th December 2018 5:00am
Location: Marengo, Illinois usa

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

Post by grayghost4 »

this is my results
Fedora
XFCE
Gambas 3.11.4
Attachments
testinst.png
testinst.png (112.92 KiB) Viewed 10770 times
User avatar
Godzilla
Posts: 63
Joined: Wednesday 26th September 2018 11:20am

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

Post 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.
Attachments
Mint 18.3 and Gambas 3.12.0 and Asus
Mint 18.3 and Gambas 3.12.0 and Asus
asus-gambas.png (67.08 KiB) Viewed 10764 times
Mint 19.1 and Gambas 3.12.0 and Acer
Mint 19.1 and Gambas 3.12.0 and Acer
acer-gambas.png (80.9 KiB) Viewed 10764 times
User avatar
stevedee
Posts: 518
Joined: Monday 20th March 2017 6:06pm

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

Post 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
User avatar
cogier
Site Admin
Posts: 1118
Joined: Wednesday 21st September 2016 2:22pm
Location: Guernsey, Channel Islands

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

Post 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: )
User avatar
stevedee
Posts: 518
Joined: Monday 20th March 2017 6:06pm

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

Post 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?
User avatar
cogier
Site Admin
Posts: 1118
Joined: Wednesday 21st September 2016 2:22pm
Location: Guernsey, Channel Islands

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

Post 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.
User avatar
Godzilla
Posts: 63
Joined: Wednesday 26th September 2018 11:20am

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

Post 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.
Post Reply