Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Petr on July 14, 2019, 05:43:53 am

Title: Bug in STRING type
Post by: Petr on July 14, 2019, 05:43:53 am
Please read this thread for more: https://www.qb64.org/forum/index.php?topic=1504.msg107105#msg107105  and other posts below.
Title: Re: Bug in STRING type
Post by: bplus on July 14, 2019, 11:37:43 am
Hi Petr,

Could there be a conflict in names between Type Wname as string *12

and this:
FUNCTION Init_Window (Wname AS STRING, ...
Title: Re: Bug in STRING type
Post by: Pete on July 14, 2019, 12:01:35 pm
He reported the bug in the original code, which had Wname as string, without the * 12 added, as in the second posting of the "degraded" version.

I've seen this happen in code when a variable is pushed over its limits. Using "INTEGER" can really bite you due to the limited numerical capacity. I notice Petr has a mix of declared INTEGER and undeclared LONG variables that interact with each other; however, he mentioned  changing suspect ones to LONG did not solve the problem.

I'm wondering instead of a bug in the new QB64 version, if this wasn't some kind of bug fix from a previous version. That's remotely possible, and worth considering. My hope is that whoever made the version changes remembers what changes were made and why. I recall when Rob switched to OpenGL, there were some graphics errors, which could only be fixed by minor tweaks in the user's code. TheBOB got bit on that one, and ironically enough, the only graphics program I made, a GUI demo, had the same problem. I actually never fixed the GL one. NOt a high priority for us SCREEN ZERO HEROES.

Pete   
Title: Re: Bug in STRING type
Post by: Petr on July 14, 2019, 12:49:50 pm
Hi BPlus, Hi Pete,

I tryied BPlus idea and replace Wname$ in function Init_Window to WindowName$ but the bug continued, if in array string declarations is not *12 in IDE 1.3

Thank you for your interest in this problem.

I will keep the string declarations with * 12 in the code for now and continue with the development in IDE 1.3 when it works. I believe, that somebody smarter than me, fix it :-D.
Title: Re: Bug in STRING type
Post by: bplus on July 14, 2019, 03:27:37 pm
Hi Petr,

Is it possible to replicate the problem in a smaller program less complex and ambitious as the one you found the problem in?
Title: Re: Bug in STRING type
Post by: Petr on July 14, 2019, 03:49:05 pm
Maybe. I try it.
Title: Re: Bug in STRING type
Post by: SMcNeill on July 14, 2019, 04:38:51 pm
I haven’t had a chance to look at the code yet (life has been very busy here, since my mother just had surgery Wednesday and we’re watching over her recovery at home), but is this an issue with use of fixed length vs null strings?  It's an issue I’ve had bite me various ways in the past.

For example:

Code: [Select]
OPEN “temp.txt” FOR OUTPUT AS #1
PRINT #1, “Hello World”
CLOSE

OPEN “temp.txt” FOR BINARY AS #1
GET #1, a$
PRINT a$
With the above, we’ll see a blank screen.  a$ has a length of 0, so the GET statement got 0 bytes from the file to fill its contents.

If we DIM a AS STRING * 11, the above will print “Hello World” for us, as we get 11 bytes from the file to fill the variables contents.

MEMGET can do the same thing, so you might want to check for that.

I wouldn’t swear it’s whats going on, but it would explain the difference in why a type AS STRING would fail, compared to a type AS STRING * 12.

Title: Re: Bug in STRING type
Post by: Petr on July 14, 2019, 05:04:57 pm
Hi. I'll take it in short. When there is only a STRING type, sometimes, for example, when you run a program for the tenth time, meaningless values start to load out of the array. I mean the run of one and the same EXE file without further recompilation. Adding a length to STRING - and this bug will no longer happen. The program uses dynamic fields. Instead of drawing grids in both upper and left lower windows, this is missing. This occurs because the FOR loop that draws the grid gets invalid values.
Title: Re: Bug in STRING type
Post by: TempodiBasic on July 14, 2019, 05:22:51 pm
Hi Steve
the issue seems to be out in this thread where a TYPE with an undefined lenght string was used with no error from QB64.

https://www.qb64.org/forum/index.php?topic=1504.msg107122#msg107122 (https://www.qb64.org/forum/index.php?topic=1504.msg107122#msg107122)

so if Petr uses a fixed string in a his UDT all is ok, if he uses an undefined lenght string Qb64 1.3 gives strange results...

IMHO it is clear that you get strange results when you don't say to compiler how much bytes you must take from memory when you use that Mytype.UndefinedString ...

my little point of view  is that  in original Qbasic and QB45 we can use only fixed string in an UDT.  If QB64 has done an enlargement of this construct of QB to the string without defining how long it is, well in that case we need a warning in compiler or a trap error to avoid the case that you have shown in your post
Quote
Code: QB64: [Select]
  1.  
  2. OPEN “temp.txt” FOR OUTPUT AS #1
  3. PRINT #1, “Hello World”
  5.  
  6. OPEN “temp.txt” FOR BINARY AS #1
  7. GET #1, a$
  9.  
  10.  
With the above, we’ll see a blank screen.  a$ has a length of 0, so the GET statement got 0 bytes from the file to fill its contents.

for example a warning that remember us if the MyType.UndefinedLenghtString is used without give it a dimension or if its LEN is 0.

thanks to read
Title: Re: Bug in STRING type
Post by: FellippeHeitor on July 14, 2019, 06:08:43 pm
Variable length strings in types is new in v1.3, and the recent discussion shows a memory leak has been found. It’ll be analyzed.
Title: Re: Bug in STRING type
Post by: TempodiBasic on July 16, 2019, 05:14:58 pm
Hi Fellippe

thanks for precision....
from a point of view of user...
this news
Quote
It is now possible to have variable-length strings in User Defined Types (UDTs).
is an empowerment of possibility to code an UDT.
if there is a inner managment of case  we need no other that to use optionally a generic string in UDT or otherwise IMHO
Quote
in that case we need a warning in compiler or a trap error to avoid the case that you have shown in your post
.
Please say me
what is the actual situation (inner managment or user managment) ?
Thanks to read
Title: Re: Bug in STRING type
Post by: SMcNeill on July 16, 2019, 09:32:59 pm
Quote from: TempodiBasic on July 16, 2019, 05:14:58 pm
Please say me
what is the actual situation (inner managment or user managment) ?
Thanks to read

If you’re talking about the code I posted, it’s up to the user to manage the issue.  Think of it as the following:

PRINT #1, a$;

Does the above need a warning label: “Warning, if a$ is null, nothing will be printed to file.”?

If not, then why would you need one for:

GET #1, , a$

“Warning: If a$ has no length, you’ll receive a null string from the file.”?

It’s up to the user to make certain they handle some things properly for themselves.

DIM a AS STRING * 12 says we’re always going to have a 12-byte string, thus we’ll always GET/PUT/PRINT/etc 12 bytes of information.

DIM a AS STRING gives us a flexible, variable length string, which may or may not be 0 bytes in length.  QB64 has no means to know what the actual, desired length should be, so it’s up to the programmer to error trap for such things themselves.

OPEN “temp.txt” FOR BINARY AS #1
a$ = SPACE$(LOF(1))
IF a$ = “” THEN
   PRINT “Error — File is blank and has no data.  Halting program.”
   END ‘or load a different file, or write a batch of default data, or however you wish to handle the problem
END IF
‘Other junk follows
Title: Re: Bug in STRING type
Post by: Petr on July 17, 2019, 01:52:14 am
In fact, the program uses both string types,  string for work in memory and the string type for working in the file. BM file for icon loading performs work in file. There is a string length calculated in program (function extract_png&), which such start and end PNG file record, then calculate PNG lenght and get it from file to PNG ile, which is then loaded as image. This use SPACE$(END RECORD position - START RECORD position) and created PNG files (if are contained in ICO) are valid.
Title: Re: Bug in STRING type
Post by: TempodiBasic on July 20, 2019, 12:54:05 pm
Hi
about news of normal string  (No fixed string) in UDT

here my code to test that has no problem for INPUT OUTPUT  BINARY , while with RANDOM mode it works if no LEN of record is defined otherwise QB64 IDE  tells to the user that UDT must have fixed size on....

Code: QB64: [Select]
  1. TYPE mystring
  2.     a AS STRING
  3.     length AS INTEGER
  5.  
  6. DIM st(1 TO 10) AS mystring, st2(1 TO 10) AS mystring
  7. WIDTH , 43
  8. '............... INPUT/OUTPUT
  9. CLS , 1
  10.  
  11. OPEN "st1.txt" FOR OUTPUT AS #1
  12. FOR t = 1 TO 10
  13.     st(t).a = STRING$(t, "-")
  14.     st(t).length = LEN(st(t).a)
  15.     PRINT st(t).a
  16.     PRINT #1, , st(t).a
  17.     PRINT #1, , st(t).length
  19.  
  22. OPEN "st1.txt" FOR INPUT AS #1
  23. FOR t = 1 TO 10
  24.  
  25.     INPUT #1, st2(t).a
  26.     INPUT #1, st2(t).length
  27.     PRINT st2(t).a;
  28.     LOCATE , 20
  29.     PRINT st2(t).length
  33. '..........................      BINARY
  34. CLS , 2
  35. OPEN "st2.txt" FOR BINARY AS #1
  36.  
  37. FOR t = 1 TO 10
  38.     st(t).a = STRING$(t, "-")
  39.     st(t).length = LEN(st(t).a)
  40.     PRINT st(t).a
  41.     PUT #1, , st(t).a
  42.     PUT #1, , st(t).length
  44.  
  46.  
  48. OPEN "st2.txt" FOR BINARY AS #1
  49.  
  50. FOR t = 1 TO 10
  51.     st(t).a = STRING$(t, "-")
  52.     st(t).length = LEN(st(t).a)
  53.     PRINT st(t).a
  54.     GET #1, , st(t).a
  55.     GET #1, , st(t).length
  57.  
  60. ',,,,,,,,,,,,,,,,,,,,,,,,, RANDOM
  61. CLS , 3
  62. OPEN "st3.txt" FOR RANDOM AS #1 'LEN = LEN(st())
  63.  
  64. FOR t = 1 TO 10
  65.     st(t).a = STRING$(t, "-")
  66.     st(t).length = LEN(st(t).a)
  67.     PRINT st(t).a
  68.     PUT #1, , st(t).a
  69.     PUT #1, , st(t).length
  71.  
  73.  
  74.  
  75. OPEN "st3.txt" FOR RANDOM AS #1 'LEN = LEN(st())
  77. FOR t = 1 TO 10
  78.     st(t).a = STRING$(t, "-")
  79.     st(t).length = LEN(st(t).a)
  80.     PRINT st(t).a
  81.     GET #1, , st(t).a
  82.     GET #1, , st(t).length
  84.  
  87.  

Thanks to read
Text Only | Text with Attachments