Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
-
- Posts: 564
- Joined: Sep 27, 2016 18:20
- Location: Valencia, Spain
Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
I have tried the latest builds of the compilers and they seem broken, reporting wrong warnings:
-----------------------------------------------------
FreeBASIC Compiler - Version 1.06.0 (08-26-2018), built for win32 (32bit)
warning 43(0): Argument count mismatch
SetWindowSubclass hCtl, CAST(SUBCLASSPROC, pWndProc), uIdSubclass, dwRefData
-----------------------------------------------------
FreeBASIC Compiler - Version 1.06.0 (08-26-2018), built for win64 (64bit)
Warning 43(0): Argument count mismatch
SetWindowSubclass hCtl, CAST(SUBCLASSPROC, pWndProc), uIdSubclass, dwRefData
warning 41(0): Return type mismatch
bi.lpfn = cast(BFFCALLBACK, @AfxBrowseForFolderProc)
where bi has been declared as bi AS BROWSEINFOW
This warning is reported by the 64 bit compiler only.
-----------------------------------------------------
They compile fine, without errors or warnings, with the previous 1.06 versions.
-----------------------------------------------------
FreeBASIC Compiler - Version 1.06.0 (08-26-2018), built for win32 (32bit)
warning 43(0): Argument count mismatch
SetWindowSubclass hCtl, CAST(SUBCLASSPROC, pWndProc), uIdSubclass, dwRefData
-----------------------------------------------------
FreeBASIC Compiler - Version 1.06.0 (08-26-2018), built for win64 (64bit)
Warning 43(0): Argument count mismatch
SetWindowSubclass hCtl, CAST(SUBCLASSPROC, pWndProc), uIdSubclass, dwRefData
warning 41(0): Return type mismatch
bi.lpfn = cast(BFFCALLBACK, @AfxBrowseForFolderProc)
where bi has been declared as bi AS BROWSEINFOW
This warning is reported by the 64 bit compiler only.
-----------------------------------------------------
They compile fine, without errors or warnings, with the previous 1.06 versions.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
It seems another instance of this bug can be found at https://freebasic.net/forum/viewtopic.p ... 30#p251230:
I suspect it might be the Windows headers..
What do the typeof statements give for you here?
At the minute I only have a 32-bit build of 1.05, which gives:
I guess for your code, it would be useful to know the types of SUBCLASSPROC, pWndProc, BFFCALLBACK, and @AfxBrowseForFolderProc.
These are all just warnings, rather than errors, which probably "just" means they are incompatible function pointer casts.
Code: Select all
#Include Once "windows.bi"
#Include Once "win/bcrypt.bi"
Type BCryptGenRandomProc As Function (Byval hAlgorithm As BCRYPT_ALG_HANDLE, Byval pbBuffer As PUCHAR, Byval cbBuffer As Ulong, Byval dwFlags As Ulong) As NTSTATUS
Dim hLib As HMODULE
Cast(BCryptGenRandomProc, GetProcAddress(hLib, "BCryptGenRandom")) 'warning 43(0):Argument count mismatch
#print typeof(BCryptGenRandomProc)
#print typeof(@GetProcAddress)
What do the typeof statements give for you here?
At the minute I only have a 32-bit build of 1.05, which gives:
Code: Select all
FUNCTION(AS ANY PTR, AS UBYTE PTR, AS ULONG, AS ULONG) AS LONG
FUNCTION(AS HINSTANCE__ PTR, AS CONST ZSTRING * 4 PTR) AS FUNCTION() AS LONG
These are all just warnings, rather than errors, which probably "just" means they are incompatible function pointer casts.
-
- Posts: 564
- Joined: Sep 27, 2016 18:20
- Location: Valencia, Spain
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
All of them are standard, as defined in the headers for version 1.05.I guess for your code, it would be useful to know the types of SUBCLASSPROC, pWndProc, BFFCALLBACK, and @AfxBrowseForFolderProc.
Defined in cmmctrl.inc
Code: Select all
type SUBCLASSPROC as function(byval hWnd as HWND, byval uMsg as UINT, byval wParam as WPARAM, byval lParam as LPARAM, byval uIdSubclass as UINT_PTR, byval dwRefData as DWORD_PTR) as LRESULT
Code: Select all
type BFFCALLBACK as function(byval hwnd as HWND, byval uMsg as UINT, byval lParam as LPARAM, byval lpData as LPARAM) as long
Besides, the warning for
warning 43(0): Argument count mismatch
SetWindowSubclass hCtl, CAST(SUBCLASSPROC, pWndProc), uIdSubclass, dwRefData
is clearly wrrong, since SetWindowSubclass has four parameters.
What they have in common is that both use the CAST keyword.
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
Have you try to compile with option '-exx' ?
-
- Posts: 4292
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
Now, that is interesting - my code went down using CAST. In my case, the CAST datatype is not from FreeBASIC but from my own UDT so it looks like the CAST expression evaluator is failing such that CAST does not get treated as a parameter. Doesn't that sound as if I know what I am talking about? <laugh> I am actually grasping at straws. It could simply be that CAST has somehow become broken in its entirety.Josep Roca wrote:What they have in common is that both use the CAST keyword.
-
- Posts: 4292
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
Just did, but no further information output.fxm wrote:Have you try to compile with option '-exx' ?
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
Here's some simple code to reproduce the warnings. As deltarho[1859] already mentioned, it seems that the casts do not really work as expected.
Code: Select all
type delegate1 as function( a as integer ) as integer
function dummy ( a as delegate1, another as integer ) as integer
return 1
end function
sub oneparam ( first as integer )
end sub
dummy(cast(delegate1, @dummy), 0) ' warning 43(0): Argument count mismatch
dummy(cptr(delegate1, @dummy), 0) ' warning 43(0): Argument count mismatch
dummy(cast(delegate1, @oneparam), 0) ' warning 41(0): Return type mismatch
dummy(cptr(delegate1, @oneparam), 0) ' warning 41(0): Return type mismatch
dummy(cast(delegate1, 0), 0) ' no warning
dummy(0, 0) ' no warning
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
Fix applied on last version:
- #642, #886: CASTs involving CONST qualifiers solved out too early allowing invalid statements to be compiled
But display now these errors seems legitimate!
This was before the compiler was too lax.
- #642, #886: CASTs involving CONST qualifiers solved out too early allowing invalid statements to be compiled
But display now these errors seems legitimate!
This was before the compiler was too lax.
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
Most changes/fixes were related to constness qualifiers, however none are involved in the example (except there are some hidden ones?). In general the changes made fbc's error checking more strict. I'm unsure whether that's the right way to go for the FreeBasic language - on one hand I like verbose error checking because it prevents potential errors, but on the other hand when sb. uses CAST one should know what he/she's doing anyway and the added verbosity makes things more complicated. For example it looks like we need special const_cast to explicitly tell the compiler when we want to cast constness away, otherwise we get warnings (however they are currently disabled by default and have to be explicitly enabled with "-w constness"). In the end we probably end in static_cast, dynamic_cast, reinterpret_cast and const_cast, as already well known from C++. I'm unsure whether that's what we really want and whether that would be beneficial for FB.
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
I'm not keen on having a variety of casts. But I did want a way to at check constness conversions, hence the they only show up when '-w constness' option is give.
For the function pointer warnings, JoseRoca submitted an issue report at https://github.com/freebasic/fbc/issues/93 and I responded there with an example program (I guessed at some types and function signatures). I think the warnings are correct.
Might help to understand if warning message text was:
- Return type mismatch in function pointer
- Calling convention mismatch in function pointer
- Argument count mismatch in function pointer
fbc is comparing the compatibility of function pointer types. Before fbc 1.06 Aug 20, there is very little type checking for function pointer types.
If fbc is generating an actual ERROR that causes compile to abort, I'd really like to see the test case.
All I can ask is that users try to assess if the warning is telling them something they should actually be aware of. If the warnings are not wanted, I can make it so they only show when compiled with '-w pedantic'.
For the function pointer warnings, JoseRoca submitted an issue report at https://github.com/freebasic/fbc/issues/93 and I responded there with an example program (I guessed at some types and function signatures). I think the warnings are correct.
Might help to understand if warning message text was:
- Return type mismatch in function pointer
- Calling convention mismatch in function pointer
- Argument count mismatch in function pointer
fbc is comparing the compatibility of function pointer types. Before fbc 1.06 Aug 20, there is very little type checking for function pointer types.
If fbc is generating an actual ERROR that causes compile to abort, I'd really like to see the test case.
All I can ask is that users try to assess if the warning is telling them something they should actually be aware of. If the warnings are not wanted, I can make it so they only show when compiled with '-w pedantic'.
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
As discussed in this thread, forcing a BASIC coder to use constructs like PrevWinProc = CAST(ANY PTR, SetWindowLongPtr(Edit_1, GWLP_WNDPROC, CAST(LONG_PTR, @SubEdit))) is UTTERLY pedantic.coderJeff wrote:If the warnings are not wanted, I can make it so they only show when compiled with '-w pedantic'.
-
- Posts: 4292
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
I would go further than that and call it draconian. <smile>jj2007 wrote:UTTERLY pedantic
If I remember correctly poseidonFB will warn but allow a compilation. WinFBE, on the other hand, will abort a compilation on a warning. If WinFBE does not change then it will not be able to use any further fbc builds unless the matter is resolved, and that includes a stable 1.06 when it eventually gets published. WinFBE, obviously, needs changing.
-
- Posts: 999
- Joined: Jul 14, 2005 23:41
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
That was changed two days ago based on fxm's suggestion in the WinFBE thread in the Project's forum.deltarho[1859] wrote:I would go further than that and call it draconian. <smile>jj2007 wrote:UTTERLY pedantic
If I remember correctly poseidonFB will warn but allow a compilation. WinFBE, on the other hand, will abort a compilation on a warning. If WinFBE does not change then it will not be able to use any further fbc builds unless the matter is resolved, and that includes a stable 1.06 when it eventually gets published. WinFBE, obviously, needs changing.
In the next update, compiles that result in only warnings will be deemed "successful".
We were already reading your mind, David :-) lol
-
- Posts: 4292
- Joined: Jan 02, 2017 0:34
- Location: UK
- Contact:
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
Magic!PaulSquires wrote:In the next update, compiles that result in only warnings will be deemed "successful".
If I may be pedantic, <smile>, rather than use the term 'deemed' I'd use 'treated as'.
BTW, I prefer not to hide the popup compile messagebox because I want to see the file size - saves me using my file manager to find out. A file size of zero also tells me that something untoward has occurred and I need to look at the Compiler Log File.
-
- Posts: 999
- Joined: Jul 14, 2005 23:41
Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken
Well then, just for you, I have added the resulting file size immediately following the successful compiled EXE filename in the status bar panel. :-)deltarho[1859] wrote:PaulSquires wrote:BTW, I prefer not to hide the popup compile messagebox because I want to see the file size - saves me using my file manager to find out. A file size of zero also tells me that something untoward has occurred and I need to look at the Compiler Log File.