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 - VonGodric - 12-12-2004 sdl sdlvideo.bi file has a bug in sdl_Rect structure: change it to: Code: type SDL_Rect Bug Reports - na_th_an - 12-29-2004 Found another one. fbc doesn't complain on this snippet but the assembler does: Code: Declare Sub DoFoo() Error messages returned: Code: test.asm: Assembler messages: Bug Reports - v3cz0r - 12-30-2004 Fixed, will be on next rls, thanks. Code: [fixed] "imm op short var" was allocating the wrong register type, due an integer imm optimization at AST (v1c) Bug Reports - na_th_an - 12-31-2004 Thanks I found another one. The compiler (or the assembler) seems to have trouble with long strings in long lines: Code: Declare Sub Pres (t$) The string "st$" resulting is trimmed in the first test whether by the compiler or the assembler. I had to manually split like 200 lines with text in my text adventure Bug Reports - Ryan - 12-31-2004 heh That's tedious. It does work fine when the string is grabbed with line input, though, as I'm just storing all the text in external files. Bug Reports - v3cz0r - 12-31-2004 Literal strings max length is now 1024 chars, enough? ;) Download the new version, btw.. it's out. Bug Reports - Sterling Christensen - 12-31-2004 Minor difference in INT function behavior. It seems like QB's INT returns a LONG, while FB's INT returns floating point: Code: PRINT INT(1000000000) I think this would cause expressions involving INT to use more floating point math than necessary. Example: Code: PRINT int% + INT(float!) This bug took me quite some time to figure out... - subxero - 12-31-2004 Alright, I was writing a program to automatically generate DECLARE statements for any SUBs/FUNCTIONs in a file/in a group of files and I needed to use three Windows API functions: FindFirstFile, FindNextFile and FindClose, as follows: Code: Declare Function FindFirstFile Lib "kernel32" Alias "FindFirstFileA" (ByVal lpFileName As String, lpFindFileData As WIN32_FIND_DATA) As Integer These functions take a parameter of type WIN32_FIND_DATA (who requires FILETIME as well): Code: Type FILETIME Now, I've got my functions and their UDTs. So let's give them a call: Code: Dim FindHandle As Integer However, that code does not work... the filenames printed are not the whole filenames - they are missing their first four characters. I suspect this is because the strings in FB are stored as (size, data), where size is a four-byte long integer. Since Windows copies strings directly to their address, it copies the first four characters into this unaccessible area of the string. So I had to work around this by doing the following: Code: ' MAX_PATH is usually 260 This worked just fine. This took me quite some time to figure out, though, and could be a serious pain in Windows programming with FB. It's just a suggestion, but might it be possible to have a CSTRING data type, that stores its strings as NULL-terminated values? It'd be a little weird, but it would work. Bug Reports - VonGodric - 12-31-2004 okay, I found new bug: Code: sub test(text as string * 1) Bug Reports - adosorken - 12-31-2004 How can a string exceed the value of another string? I think your code is what's broken. |