Bugs
Re: Bugs
I agree.
Re: Bugs
The problem is due to a FPU instruction converting float to a WORD (16 bits) : FISTP.
In case of overflow the value stored in memory is always the 'integer indefinite value' = 32768.
gcc32 uses also FISTP but with DWORDs (32 bits) so no problem.
Normaly in case of 'integer indefinite value' as it's a possible value a flag should be tested. Maybe a runtime error could be thrown.
In case of overflow the value stored in memory is always the 'integer indefinite value' = 32768.
gcc32 uses also FISTP but with DWORDs (32 bits) so no problem.
Normaly in case of 'integer indefinite value' as it's a possible value a flag should be tested. Maybe a runtime error could be thrown.
Re: Bugs
I thought so.fxm wrote: ↑Nov 20, 2022 16:39 Line 76, '&0' inside a concatenation expression is misinterpreted by the parser of fbc 1.10.0 ('&0' is now an octal literal)
To be replaced for example with '& 0'.
Due to changelog.txt (Version 1.10.0):
- sf.net #455: fbc: Allow &nnn... octal literals in source (like VALINT and friends)
@Jeff,
Is this change really useful ?
Code: Select all
print cint("&17") '' allowed since always, but
print &17 '' error in fbc<=1.09.0? why? isn't this what QB allowed?
Re: Bugs
I have recently been working on bug fixes with SARG that has to with return user defined types (UDTs) by value from structures.
It's one of things that may or may not break binary compatibility, depending on user code, unfortunately.
Anyway, this particular bug comes up in the following scenarios:
- mixing modules compiled with different backends: -gen gcc + -gen gas, or -gen gcc + -gen gas64, even if all compiled with fbc
- mixing fbc with c libraries - i.e. calling c (gcc) libraries that return structures by value
- using different tool chains - i.e. mingw-w64 gcc 5.2 expects different code generation than winlibs gcc 9.3 for structures returned by value.
It only happens for some kinds of structures, some targets, some backends.
For example:
These structures returned by value from functions may fail.
Anyway, it's something that needs to be fixed, and at the very least improved. We will be pushing changes for the fixes soon and I apologize if it breaks binary compatibility (libraries) for user code. And I apologize if we need to fix / improve again in future. The test procedure is long and tedious, so it's quite a bit of work to check on multiple targets and tool chains.
I was hoping to build official releases this month, but not sure if we will get everything stable enough.
It's one of things that may or may not break binary compatibility, depending on user code, unfortunately.
Anyway, this particular bug comes up in the following scenarios:
- mixing modules compiled with different backends: -gen gcc + -gen gas, or -gen gcc + -gen gas64, even if all compiled with fbc
- mixing fbc with c libraries - i.e. calling c (gcc) libraries that return structures by value
- using different tool chains - i.e. mingw-w64 gcc 5.2 expects different code generation than winlibs gcc 9.3 for structures returned by value.
It only happens for some kinds of structures, some targets, some backends.
For example:
Code: Select all
type udt_4
f0 as long
end type
type udt_121f
f0 as byte
f1 as short
f2 as byte
f3 as single
end type
Anyway, it's something that needs to be fixed, and at the very least improved. We will be pushing changes for the fixes soon and I apologize if it breaks binary compatibility (libraries) for user code. And I apologize if we need to fix / improve again in future. The test procedure is long and tedious, so it's quite a bit of work to check on multiple targets and tool chains.
I was hoping to build official releases this month, but not sure if we will get everything stable enough.
Re: Bugs
Could somebody test this please.
Run this (quick run will do)
Now select all and copy from the console.
Paste somewhere, notepad say.
Only the first string is shown here, the second string (s1) doesn't copy from the console here.
Win 10, fb 1.09
I am not fussy about all the characters showing correctly (in an ide say), just that the second string seems ignored.
Run this (quick run will do)
Code: Select all
dim as zstring * 300 s=""
dim as string s1=""
for n as long=0 to 255
s+= chr(n)
next
print s
print
print
for n as long=0 to 255
s1+= chr(n)
next
print s1
print
print
sleep
Paste somewhere, notepad say.
Only the first string is shown here, the second string (s1) doesn't copy from the console here.
Win 10, fb 1.09
I am not fussy about all the characters showing correctly (in an ide say), just that the second string seems ignored.
Re: Bugs
You cannot put text with embedded null characters in the clipboard (the following characters are suppressed).
Only the the string 's1' concatenation has kept this character in the first position, the zstring 's' concatenation has naturally removed it.
Only the the string 's1' concatenation has kept this character in the first position, the zstring 's' concatenation has naturally removed it.
Re: Bugs
Thanks fxm.
The strange thing in c++ the console can be copied.
This is all to do with the practrand random number testing in the other thread which reads stdout (via the clipboard??), I don't know the innards of practrand.
But c++ code and fb code doing the same thing have different results.
I am trying to figure out why.
The strange thing in c++ the console can be copied.
Code: Select all
☺☻♥♦♣
♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~⌂ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®¬½¼¡«»░▒▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýݯ´±‗¾¶§÷¸°¨·¹³²■
--------------------------------
Process exited after 0.0684 seconds with return value 0
Press any key to continue . . .
Code: Select all
#include<iostream>
int main()
{
int n;
for (n=0;n<256;n++)
std::cout<<char(n);
}
But c++ code and fb code doing the same thing have different results.
I am trying to figure out why.
Re: Bugs
Pascal also copies from the consoledodicat wrote: ↑Mar 27, 2023 16:06 Thanks fxm.
The strange thing in c++ the console can be copied.Code: Select all
☺☻♥♦♣ ♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~⌂ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®¬½¼¡«»░▒▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýݯ´±‗¾¶§÷¸°¨·¹³²■ -------------------------------- Process exited after 0.0684 seconds with return value 0 Press any key to continue . . .
This is all to do with the practrand random number testing in the other thread which reads stdout (via the clipboard??), I don't know the innards of practrand.Code: Select all
#include<iostream> int main() { int n; for (n=0;n<256;n++) std::cout<<char(n); }
But c++ code and fb code doing the same thing have different results.
I am trying to figure out why.
Code: Select all
☺☻♥♦♣
♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~⌂Çüéâäà
åçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®¬½¼¡«»░▒▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýݯ´±‗¾¶§÷¸°¨·¹³²
■
Re: Bugs
This does the job in fb
result from clipboard:
Code: Select all
#include "crt.bi"
_setmode( _fileno( stdout ), _O_BINARY )
dim as string s
for m as long=0 to 255
s+= chr(m)
next
fwrite(@s[0], len(s), 1, stdout)
sleep
Code: Select all
☺☻♥♦♣
♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~⌂Çüéâäà
åçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®¬½¼¡«»░▒▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýݯ´±‗¾¶§÷¸°¨·¹³²
■
Re: Bugs
The SetLayeredWindowAttributes is not working any more (Windows).
This function lets you create semi transparent windows.
In fb 1.07.2 it was working OK, and that was the last time I used it in code. (Until today)
HELLO should be printed to the window:
This function lets you create semi transparent windows.
In fb 1.07.2 it was working OK, and that was the last time I used it in code. (Until today)
HELLO should be printed to the window:
Code: Select all
Declare Function SLWA Alias "SetLayeredWindowAttributes" (Byval As Any Ptr, Byval As Ulong, Byval As Ubyte, Byval As long) As boolean
#define shaped 16
#define alpha_blend 64
#define OnTop 32
#define GetWindowHandle 2
Sub BlendWindow( Byval Alpha_Value As Ubyte )
static Win As Any Ptr
if win=0 then
var Ip = Cptr(Integer Ptr,@Win )
Screencontrol GETWINDOWHANDLE, *Ip
end if
if SLWA (Win,Rgb(255,0,255),Alpha_Value,2 Or 1)=true then beep
End Sub
Screenres 1024,768,32,,SHAPED Or ALPHA_BLEND Or ONTOP
screenlock
cls
blendwindow(155)
locate 5,5
print "HELLO"
screenunlock
sleep
Re: Bugs
When you turn on ShapedWindow with the D2D driver (I think that's the default now), it uses UpdateLayeredWindow to well, update the window since Window shapes are still a GDI-only thing even in the fancy world of DirectX stuff.
Unfortunately...
Maybe it would've been better for the D2D driver to nope out if shaped windows were requested, but that's how it is for now.
The recourse is to force usage of the GDI driver instead of the D2D one. Someone else will have to tell you what the setting/define is, because I've forgotten how to do it.
Unfortunately...
So it stops drawing anything since it can't update the window.https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setlayeredwindowattributes wrote: Note that once SetLayeredWindowAttributes has been called for a layered window, subsequent UpdateLayeredWindow calls will fail until the layering style bit is cleared and set again.
Maybe it would've been better for the D2D driver to nope out if shaped windows were requested, but that's how it is for now.
The recourse is to force usage of the GDI driver instead of the D2D one. Someone else will have to tell you what the setting/define is, because I've forgotten how to do it.
Re: Bugs
Code: Select all
#include "fbgfx.bi"
Dim As String driver
'' set graphics driver to GDI, before calling Screen
ScreenControl FB.SET_DRIVER_NAME, "GDI"
Screen 12
'' fetch graphics driver name and display it to user
ScreenControl FB.GET_DRIVER_NAME, driver
Print "Graphics driver name: " & driver
Sleep
Re: Bugs
Thank you both.
SetEnviron("fbgfx=GDI")
fixes the problem.
SetEnviron("fbgfx=GDI")
fixes the problem.
Re: Bugs
This code:
Compile with:
I get the error:
When I compile without the "-r" option, there is no error.
Code: Select all
If ( __FB_ARGC__ = 1 ) Then
Print 1
End If
Code: Select all
fbc64.exe -r file.bas
Code: Select all
file.bas(1) error 42: Variable not declared, __FB_ARGC__ in 'If ( __FB_ARGC__ = 1 ) Then'