Reading garbage from data

[felixp7]

All right, I'm new to BaCon and might be missing something obvious (also using version 3.7.2, so it could be a bug that was fixed in the mean time). When running the attached test program, I get a strange garbage value in the middle of the last DATA row. The curious part is, when the same code is part of a larger program, most values are garbage like that. I'd blame my hardware, but the values returned seem consistent. I'd blame a miscount causing me to read past the end of data, but I double-checked my numbers and all seems fine. Halp!

P.S. Couldn't find anything related to that in the forum. Hopefully my search-fu isn't failing me now of all times.

Attachments:

read-data.bac (5.23 KB)

[vovchik]

Dear felixp7,

Welcome to the forum, and thanks for your contributions. I checked your test program on Mint 19.2 (64 bit) and everything seems OK. I have attached the output. It is weird that you are getting garbage results. Peter might have an idea...

With kind regards,
vovchik

Attachments:

vovdata.txt.tar.gz (389 B)

[rikky]

Yes, I checked, you're right.
I narrowed it down to I = t_rubble AND Y = 15 AND X = 9  gives => 2147483647
FOR I = 0 TO 7
READ colors$
'PRINT colors$
NEXT

FOR I = t_nothing TO t_rubble
FOR Y = 0 TO 15
FOR X = 0 TO 15
READ idx

IF I = t_rubble AND Y = 15 AND X = 9 THEN
 PRINT STR$(X) & " : ";
 PRINT idx
END IF

NEXT
'PRINT
NEXT
'PRINT
NEXT
I swapped the rubble data with the village data
Made the CONST t_village = 5 and the CONST t_rubble = 4

And now the error occures in
I = t_village AND Y = 15 AND X = 9  gives => 2147483647

Unbelievable. 
This cannot be real,

[rikky]

Ah, It appears that your mountain block has one dataline to short.

 Rik.

[Pjot]

Dear felixp7,

Rik was faster than me - well done Rik!

@ vovchik: on my Mageia Linux I also got the same result, but this result is coincidence, as the random data seems to be initialized to 0.

HTH
Peter

[felixp7]

Ha! That's what I get for converting data manually, but it was an expedient. With the missing data line, the test program now works flawlessly. That's the good news. The bad news is, making the exact same correction in my actual code resulted in... unchanged behavior. All the data appeared corrupted, almost from the start. Or rather, all the numeric data; the color names were getting read in just fine. On a whim, I tried moving my entire data block to the start of the program, even before the `INCLUDE "hug.bac"` line... and now it also works fine.

I'd suspect it needs a RESTORE to the start of data, even though it shouldn't, but that was one of the first things I tried before asking for help, and it had no effect. So. Weird. Any ideas?

[Pjot]

Oct 12, 2019 14:11:54 GMT 1 felixp7 said:

The bad news is, making the exact same correction in my actual code resulted in... unchanged behavior. All the data appeared corrupted, almost from the start. Any ideas?

Well, it might be that you've missed some more lines of DATA. Another common mistake is the counting of array indexes; an array of 16 elements ranges from 0-15. Please check if your code has the correct index counting in place.

Apart from these ideas, it will be hard to find a cause without your code. We need to be able to reproduce your error so please provide a code snippet which shows the problem. As you may have observed, we're happy to troubleshoot it further

BR
Peter

[felixp7]

Well, it might be that you've missed some more lines of DATA. Another common mistake is the counting of array indexes; an array of 16 elements ranges from 0-15. Please check if your code has the correct index counting in place.

No I didn't, the data was copy-pasted back and forth, and so was the code that reads it. Besides, as I pointed out above, moving the entire block of data to the very start of my code, with no other changes whatsoever, caused the program to work perfectly all of a sudden. (See the other thread.) In fact we could declare the problem solved... except now we have a mystery on our hands. Why would it matter where the DATA statements are located? The only idea I have is a bug not in BaCon, but in my gcc. But how would I test that?

[Pjot]

Hi felixp7,

Indeed, when I put the INCLUDE statement before your original 'read-data.bac' code, the reading of the DATA shows unexpected results.

The reason for this is that the "hug.bac" context itself also uses READ/DATA statements. The internal housekeeping to keep track of the DATA does not take an INCLUDE statement into account.

This is an unexpected side-effect. Some would call it a bug

To overcome this problem, you can use LABEL and RESTORE. So you have to change your code as follows:

LABEL here

DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
<...more data...>

RESTORE here

READ idx
<...etc...>


I have fixed this issue in the latest beta.

BR
Peter

[felixp7]

Go figure. I suspected restoring to a label would be needed, but placed it after the color name data, because that part was being read in correctly. So it didn't seem to help. Oh well, I know better now. Thank you so much!