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.

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?

Hi, cogier. Sure.


Without running the code, I would expect the output of this to be:


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:


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.

 this is my results
Fedora
XFCE
Gambas 3.11.4

(Click to enlarge)

 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.

Mint 19.1 and Gambas 3.12.0 and Acer

(Click to enlarge)

 What happens if you replace gb.IgnoreCase with 1

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

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.

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: )

cogier said

… 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?

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

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.

 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.

This is a Gambas bug. The problem exits on openSUSE Leap 15 also. Worked ok with Gambas 3.11.x, but not with 3.12.x. I imagine it will also fail on my Debian 9.6 box if I were to upgrade Gambas from 3.11.x to 3.12.x (update not in my repo yet).

I tried to install 3.12 on my Fedora laptop computer .. but it will not configure or make …. many errors.  8-)

I put up a bug report on the Mailing list pointing to this thread and received the following: -

Le 03/01/2019 à 17:34, Charlie Ogier a écrit :
Hi Benoît,

Have a look at this thread
Gambas One - Gambas ONE

Charlie
 

It has been fixed in the last commit. I will release a 3.12.1 version as
soon as possible.

Regards,

Benoît Minisini

Sorted

 cogier thank you for bringing this to Benoît Minisini's attention. I'm glad he's on it, and happy to hear that the fix is already coded and will be in the upcoming release.

String.InStr will suffice for everyone who upgraded to in 3.12.0, for code that must be relied on until then. I'll see if I can edit this thread's title, preface it with [Solved], and change it to your mailing list title so it makes more sense.