Author Topic: BASIC odities 2 in QB64 or qb's INSTR bug/incongruent feature  (Read 3464 times)

0 Members and 1 Guest are viewing this topic.

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
BASIC odities 2 in QB64 or qb's INSTR bug/incongruent feature
« on: September 28, 2019, 06:35:18 am »
Hi guy
just to talk of phylosophy like bugward compatibility...

an example INSTR function of QBasic

Read here before go down with discussion:
this post is to talk about the need to have original bug in the keyword of ancient QB and not to change the ancient QB's keywords

run this code to experience the matter
Code: QB64: [Select]
  1.     IF INSTR("WASD", UCASE$(in$)) THEN PRINT in$ + "1": EXIT WHILE
  2.  
  3.     IF INSTR("", UCASE$(in$)) THEN PRINT in$ + "2": EXIT WHILE: ELSE LOCATE 3, 1: PRINT INSTR("", UCASE$(in$))
  4.  

as you can see from output
  [ You are not allowed to view this attachment ]  

how do we arrive there?
1. INKEY$ passes a null string to in$ until the user press a key
2. so in first cycle in$ =""
3. INSTR gives as result a positive number if it searches a NULLstring in a String of whatYouWant so the condition of the first IF is true and the flow of program PRINTs and goes on.
4. arriving at the second loop of WHILE , in$ is again a NULLstring and going in the IF condition  INSTR gives as result 0 because for its nature it thinks that a NULLstring is 0 times in a NULLstring, because this time the string in which INSTR searches is a NULLstring.
5. so the second cycle WHILE goes on to the infinite because a NULLstring gives 0
6. when user press a key (for example spacebar)  in$ = key (chr$(32)) INSTR gives a different result that activate the EXIT WHILE but not the PRINT ins$ + "2"
7.
using this debug code after second WHILE
Code: QB64: [Select]
  1. PRINT in$ + "2"
  2. PRINT INSTR("", UCASE$(in$))
  3. s$ = ""
  4. PRINT s$ + "3"
  5.  
we get as output  this

  [ You are not allowed to view this attachment ]  

so the same PRINT works out of IF
so it seems that INSTR gives again 0 as result but this 0 is special condition because it activates the condition IF and goes out of WHILE

Now here starts the run to think/imagine what is the inner structure of INSTR :-)

I can affirm surely that the issue is about the nature of INSTR and not how it is converted in C++
why?
Simply try to run the code in QB45 or QBasic... you get the same output and behaviour of the program....
[it is fake because you must change the WHILE code... see here https://www.qb64.org/forum/index.php?topic=1748.0 ]


Good Phylosophycal thoughts friends

« Last Edit: September 28, 2019, 06:45:54 am by TempodiBasic »
Programming isn't difficult, only it's  consuming time and coffee