Bug Reports - Printable Version +- Qbasicnews.com (http://qbasicnews.com/newforum) +-- Forum: General (http://qbasicnews.com/newforum/forum-6.html) +--- Forum: General/Misc (http://qbasicnews.com/newforum/forum-18.html) +--- Thread: Bug Reports (/thread-5202.html) |
Bug Reports - v3cz0r - 12-06-2004 Ops, a typo at rtl.bas: data "csrline", "fb_ConsoleGetY", FB.SYMBTYPE.INTEGER,FB.FUNCMODE.STDCALL, 0 "csrline" instead of "csrlin", fixed. Bug Reports - na_th_an - 12-06-2004 Great news You're fast man. Bug Reports - Sterling Christensen - 12-06-2004 This code: Code: dim i as integer Code: bug1.asm: Assembler messages: Bug Reports - v3cz0r - 12-06-2004 Thought GAS was smart enough to convert ESI*3 to ESI*2+ESI, my bad.. got too used to MASM/TASM.. will fix asap.. Bug Reports - na_th_an - 12-06-2004 I found what looks like some nasty corruption of string variables. I'm working on translating an old text adventure I wrote into English but first I wanted to make it run in FB. Almost no changes, and it got compiled. Everything looked fine, but when I played a few turns it began to act strange. There is a SUB that is passed a string with the room ID (i.e. "TOWN"). It opens the locations file, and looks for the ID inside. The first time I run the game it works fine, i.e. it finds the line and reads upon it. The code is as simple as: Code: DO When I exit that room and enter again, the line is not found. It only happens with some rooms, not with every one. I changed the code. Coded a simple comparator: Code: Function compare%(in1$, in2$) Still fails. I added prints to see what's happenning (great way of debugging, isn't it? ) and the first time it works great. It receives "TOWN" and "TOWN" and returns -1 (true). The second time it is called with "TOWN" and "TOWN" it reports that the first string is 25 characters long instead of 4, so it fails and returns 0. Extremely odd, taking in acount that I used RTRIM$ and LTRIM$ inside the function and before calling it. This line: Code: PRINT in1$;"|";LEN(in1$) Outputs: Code: TOWN| 25 I can't be more helpful. I could post the code, but it's a big project and in Spainsh... a pain to check. But if you like... Bug Reports - adosorken - 12-06-2004 Code: Type BITMAPHEADER Btw, I'm using the very latest version, the one you just released. Bug Reports - SJ Zero - 12-06-2004 This is nit-picking(but then, it's programming, so I suppose...), but the STR$ function should have a space before the number. FB: "0"+str$(1)+"0" = "010" QB: "0" + str$(1) + "0" = "0 10" Bug Reports - na_th_an - 12-06-2004 Hmmm Found something. I'm using a fixed length string to see what's happenning: Code: Function compare%(in1$, in2$) The first time the function is called, it shows it good. T, O, W, N, and then 36 null chars. The next time it is called for "TOWN", I am getting T, O, W, N, a null char, and then other chars, that are exactly ' ', 'S', 'U', 'R', ' ', 'D', 'E', 'L', ' ', 'C', 'A', 'M', 'I', 'N', 'O', ' ', 'S', 'E', 'C', 'O'... Filling until precisely char #25, then null chars again. The variable that's passed to the function was given "TOWN", it worked, then it was given "PARTE SUR DEL CAMINO SECO", it worked, and then it was given "TOWN" again, and I got what I showed. See what I mean? (# is the null char) Code: TOWN# All are variable-length strings. I've patched my program to have it working. This does the trick: Code: DIM fixBug AS STRING * 80 Bug Reports - adosorken - 12-06-2004 Okay...I found a way around the error I was getting. It appears to be an error in the Type (the first entry seems to believe it's an Integer rather than a Short for some reason!). If an Integer is first in a Type, it looks like it works fine, but a Short as first in a Type and it looks like it throws a tantrum. Then again, as I'm off to bed now, I'm unable to test this theory. Can anyone confirm this potential bug? Bug Reports - v3cz0r - 12-06-2004 Nek: all UDT elements are aligned and the UDT size is rounded to multiple of len( integer ) - all 32-bit C compilers do the same by default. To turn that off, use: Type BITMAPHEADER Field=1 ... End Type No alignament or padding will be done then. Zero: Yeah, i know it, it's on purpose, i always hated to use ltrim$( str$( value ) ), but then its just me.. Nathan: I will check it tomorrow, i think it's not the string comparator, i tested it using some old sorting algos made for qb and results were the same, it could be the data read from file, i could have missed some detail from LINE INPUT or something - that test with fixed len is okay, LEN used on a fixed-len will return it's full size, as in QB, but FB does not pad the fixlen string with spaces, but puts a null-term on it (RTRIM$ checks for the null too, besides the spaces). |