View previous topic :: View next topic |
Author |
Message |
Zitronenfalter
Joined: 23 Aug 2010 Posts: 12
|
Posted: Wed Aug 21, 2019 10:36 am Post subject: Function Instr, faulty response since version 2.0.8.2 |
|
|
Hello
The Function Instr in Version 2.0.8.2 shows an incorrect result if the search string is embedded within {} (e.g. "{034}" for the quotation mark).
Code: | $regfile = "m48def.dat"
$crystal = 4000000
$baud = 19200
$hwstack = 32
$swstack = 10
$framesize = 40
Dim String1 As String * 20
Dim String2 As String * 1
Dim Found As Byte
String1 = "abcdefghijklmno"
String2 = "g"
Found = Instr(1 , String1 , String2)
' Result:
' Found (2081) = 7
' Found (2082) = 7
Found = Instr(1 , String1 , "g")
' Result:
' Found (2081) = 7
' Found (2082) = 7
Found = Instr(1 , String1 , "{103}") ' Chr(103 = "g"
' Result:
' Found (2081) = 7
' Found (2082) = 0
|
(BASCOM-AVR version : 2.0.8.2 ) |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Wed Aug 21, 2019 12:22 pm Post subject: |
|
|
i tested and confirm it is a bug. will have a look at it. _________________ Mark |
|
Back to top |
|
|
Zitronenfalter
Joined: 23 Aug 2010 Posts: 12
|
Posted: Fri Jul 10, 2020 12:01 pm Post subject: |
|
|
I noticed today that the function INSTR returns zero for a search string consisting of Chr(13)+Chr(10) although this string is in the string to be searched. |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Fri Jul 10, 2020 1:57 pm Post subject: |
|
|
please post a small example so it can be checked. _________________ Mark |
|
Back to top |
|
|
Zitronenfalter
Joined: 23 Aug 2010 Posts: 12
|
Posted: Fri Jul 10, 2020 3:34 pm Post subject: |
|
|
Sorry, now I wanted to write a small program but apparently this part of the function works.
But in my "big" program it does not work.
Somehow a local variable containing the search string is changed.
If the search string is global, the function works as it should. But that should not be your problem now. |
|
Back to top |
|
|
JC
Joined: 15 Dec 2007 Posts: 585 Location: Cleveland, OH
|
Posted: Fri Jul 10, 2020 6:05 pm Post subject: |
|
|
IN addition to your normal debugging, make sure your Stacks and Framesize are adequate.
JC |
|
Back to top |
|
|
Zitronenfalter
Joined: 23 Aug 2010 Posts: 12
|
Posted: Sat Jul 11, 2020 8:16 am Post subject: |
|
|
I was also thinking of the stack in this context.
But even the increase from 300 to 350 and even more bytes did not bring success. The one new local variable with its two bytes would have to be IMHO with the additional 50 bytes.
For some reason I can't see, this one string variable is empty even though it was previously assigned to Chr(13)+Chr(10).
The used controller (ATmega1284p) should have enough RAM.
If you can rely on the report only approximately, my application currently needs about 7kByte RAM.
I have had problems with such big controllers where the compiler was "swallowed up" by the size.
It even happened sometimes that a program part at one position in the program listing did not work (or better said differently) and moving the program part then delivered the expected flow of the program. I would like to explain this with the fact that there might be a problem with "page-spanning" (IMHO 64kByte) program parts which then only become effective under certain circumstances.
As far as I remember, there was also a problem with a somewhat longer "DO-WHILE-listing". The exit did not work then. But it did after simply moving the program part within the listing.
But as long as I can "circumvent" it, it doesn't bother me. |
|
Back to top |
|
|
Zitronenfalter
Joined: 23 Aug 2010 Posts: 12
|
Posted: Sat Jul 11, 2020 10:10 am Post subject: |
|
|
I could solve the problem now.
The reason was the order of declaration of the two local variables and in consequence the assignment of a byte variable with the return value of a function as dWord.
To my excuse I only want to add that I had improved an older program and through the new BasCom version just stumbled over the error described in the incoming mail and wanted to apply the workaround in form of a string variable.
The error described in the incoming mail still exists, of course.
Here the error was clearly sitting in front of the screen. |
|
Back to top |
|
|
|