Bug Reports

[v3cz0r]

Ops, a typo at rtl.bas: data "csrline", "fb_ConsoleGetY", FB.SYMBTYPE.INTEGER,FB.FUNCMODE.STDCALL, 0

"csrline" instead of "csrlin", fixed.

[na_th_an]

Great news You're fast man.

[Sterling Christensen]

This code:

Code:

dim i as integer
dim palBuf(0 to 255, 0 to 2) as ubyte

palBuf(i, 0) = 0

Give this error with 0.04b:

Code:

bug1.asm: Assembler messages:
bug1.asm:31: Error: expecting scale factor of 1, 2, 4, or 8: got `3'

[v3cz0r]

Thought GAS was smart enough to convert ESI*3 to ESI*2+ESI, my bad.. got too used to MASM/TASM.. will fix asap..

[na_th_an]

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
   LINE INPUT #f%, nLine$
   IF nLine$ = ":" + roomID$ THEN
      found% = -1
   END IF
LOOP WHILE NOT EOF(#f%) AND NOT found%

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$)
    in1$ = ucase$(ltrim$(rtrim$(in1$)))
    in2$ = ucase$(ltrim$(rtrim$(in2$)))
    
    if len(in1$)<>len(in2$) then
        compare% = 0
        exit Function
    end if

    for it% = 1 to Len(in1$)
        md1$ = mid$(in1$, it%, 1)
        md2$ = mid$(in2$, it%, 1)
        if md1$ <> md2$ then
            compare% = 0
            exit Function
        end if
    next it%

    compare% = -1
End Function

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...

[adosorken]

Code:

Type BITMAPHEADER
  bfType As Short
  bfSize As Integer
  bfReserved As Integer
  bfOffBits As Integer
  biSize As Integer
  biWidth As Integer
  biHeight As Integer
  biPlanes As Short
  biBitCount As Short
  biCompression As Integer
  biSizeImage As Integer
  biXPelsPerMeter As Integer
  biYPelsPerMeter As Integer
  biClrUsed As Integer
  biClrImportant As Integer
End Type

This is clearly 54 bytes long. Yet it's being returned as 56 bytes long, and the function I've written fails because something in there is getting messed up. I even tried substituting the header for a fixed length 54 byte string and then just reading the file manually and I still get no results. Is there a problem with certain kinds of variables? I'm using Ubytes to read data from the file, and of course, this header to read the header data all at once. I'm reading in a 24 bpp BMP image, so there's no palette to be worried with. Basically...the code I'm using is a direct port of the same function I used in VC.

Btw, I'm using the very latest version, the one you just released.

[SJ Zero]

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"

[na_th_an]

Hmmm

Found something.

I'm using a fixed length string to see what's happenning:

Code:

Function compare%(in1$, in2$)

    Dim FixLength as string * 40

    FixLength = in2$

    for i%=1 to len(fixlength)
        print mid$(fixlength,i%,1);"->";asc(mid$(fixlength,i%,1));"|";
    next i%

... etc

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#
PARTE SUR DEL CAMINO SECO#
TOWN# SUR DEL CAMINO SECO#

All are variable-length strings.

I've patched my program to have it working. This does the trick:

Code:

DIM fixBug AS STRING * 80

fixBug = varLengthStringThatFail$
varLengthStringThatFail$ = fixBug

[adosorken]

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?

[v3cz0r]

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).