Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

General FreeBASIC programming questions.
Josep Roca
Posts: 449
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby Josep Roca » Aug 29, 2018 10:37

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.
counting_pine
Site Admin
Posts: 6173
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby counting_pine » Aug 29, 2018 19:44

It seems another instance of this bug can be found at viewtopic.php?p=251230#p251230:

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

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


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.
Josep Roca
Posts: 449
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby Josep Roca » Aug 29, 2018 20:14

I guess for your code, it would be useful to know the types of SUBCLASSPROC, pWndProc, BFFCALLBACK, and @AfxBrowseForFolderProc.


All of them are standard, as defined in the headers for version 1.05.

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


Defined in shlobj.inc

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


pWndProc is a pointer to a callback function and @AfxBrowseForFolderProc is a pointer to another callback function.

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.
fxm
Posts: 9250
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby fxm » Aug 29, 2018 20:39

Have you try to compile with option '-exx' ?
deltarho[1859]
Posts: 2080
Joined: Jan 02, 2017 0:34
Location: UK

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby deltarho[1859] » Aug 29, 2018 20:57

Josep Roca wrote:What they have in common is that both use the CAST keyword.

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.
deltarho[1859]
Posts: 2080
Joined: Jan 02, 2017 0:34
Location: UK

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby deltarho[1859] » Aug 29, 2018 21:02

fxm wrote:Have you try to compile with option '-exx' ?

Just did, but no further information output.
St_W
Posts: 1476
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby St_W » Aug 29, 2018 21:25

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
fxm
Posts: 9250
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby fxm » Aug 29, 2018 21:53

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.
St_W
Posts: 1476
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby St_W » Aug 29, 2018 22:26

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.
coderJeff
Site Admin
Posts: 3118
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby coderJeff » Aug 29, 2018 22:49

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'.
jj2007
Posts: 1259
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby jj2007 » Aug 29, 2018 23:22

coderJeff wrote:If the warnings are not wanted, I can make it so they only show when compiled with '-w pedantic'.
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.
deltarho[1859]
Posts: 2080
Joined: Jan 02, 2017 0:34
Location: UK

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby deltarho[1859] » Aug 29, 2018 23:56

jj2007 wrote:UTTERLY pedantic

I would go further than that and call it draconian. <smile>

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.
PaulSquires
Posts: 786
Joined: Jul 14, 2005 23:41
Contact:

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby PaulSquires » Aug 30, 2018 0:13

deltarho[1859] wrote:
jj2007 wrote:UTTERLY pedantic

I would go further than that and call it draconian. <smile>

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.


That was changed two days ago based on fxm's suggestion in the WinFBE thread in the Project's forum.
In the next update, compiles that result in only warnings will be deemed "successful".

We were already reading your mind, David :-) lol
deltarho[1859]
Posts: 2080
Joined: Jan 02, 2017 0:34
Location: UK

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby deltarho[1859] » Aug 30, 2018 1:55

PaulSquires wrote:In the next update, compiles that result in only warnings will be deemed "successful".

Magic!

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.
PaulSquires
Posts: 786
Joined: Jul 14, 2005 23:41
Contact:

Re: Free Basic Compilers Version 1.06.0 (08-26-2018) seem broken

Postby PaulSquires » Aug 30, 2018 2:05

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.

Well then, just for you, I have added the resulting file size immediately following the successful compiled EXE filename in the status bar panel. :-)

Return to “General”

Who is online

Users browsing this forum: No registered users and 1 guest