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

General FreeBASIC programming questions.
Post Reply
jj2007
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

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

Post by jj2007 »

Josep Roca wrote:BTW in Petzold's times SetWindowSubClass did not exist yet.
Yes, I know, it's for ComCtl32.dll version 6, and SetWindowSubClass is a huge step forward, of course. I see the difference between WndProc and SubClassProc: One takes four parameters, the other takes six. That is a big difference, of course.
Now the question: Do you use also a dedicated type e.g. for CreateWindowEx because it takes eleven parameters, and another type for SetFocus, which takes only one?
Josep Roca
Posts: 564
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

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

Post by Josep Roca »

> Now the question: Do you use also a dedicated type e.g. for CreateWindowEx because it takes eleven parameters, and another type for SetFocus, which takes only one?

Sorry, but I don't see any relation about calling a function and passing a pointer to a callback.

The problem comes because the pfnSubclass parameter has been declared as SUBCLASSPROC

Code: Select all

declare function SetWindowSubclass(byval hWnd as HWND, byval pfnSubclass as SUBCLASSPROC, byval uIdSubclass as UINT_PTR, byval dwRefData as DWORD_PTR) as WINBOOL
and SUBCLASSPROC as

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
If you want to disable type checking, you can declare it as ANY PTR

Code: Select all

declare function SetWindowSubclass(byval hWnd as HWND, byval pfnSubclass as ANY PTR, byval uIdSubclass as UINT_PTR, byval dwRefData as DWORD_PTR) as WINBOOL
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Post by coderJeff »

Josep Roca wrote:The problem comes because the pfnSubclass parameter has been declared as SUBCLASSPROC

Code: Select all

declare function SetWindowSubclass(byval hWnd as HWND, byval pfnSubclass as SUBCLASSPROC, byval uIdSubclass as UINT_PTR, byval dwRefData as DWORD_PTR) as WINBOOL
SetWindowSubclass(...) is expecting a SUBCLASSPROC function pointer. Is it actually safe to give it something else instead?
Josep Roca
Posts: 564
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

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

Post by Josep Roca »

Of course not, but this is not what we were talking about. What were talking is that many find annoying the strict type checking, that in cases such SetWindowLongPtr, that exepects a pointer or an scalar forces to use casting, although the called function does not care. Or SendMessage, that also accepts pointers and scalars.

Some think that this goes in detriment of the acceptance from beginners that don't expect such difficulties from a Basic compiler.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Post by coderJeff »

Josep Roca, OK, I think understand now. The complaint, while related, is not new to this recent Aug 2018 version change:

Code: Select all

'' since fbc version >= 0.16.0
#include "windows.bi"
dim h as HWND, w as WNDPROC
SetWindowLongPtr( h, GWLP_WNDPROC, w )  '' warning: passing pointer to scalar
fbc windows headers just follow what is in msdn. And in this particular case of SetWindowLongPtr(), I think is to ensure that the code works on 32bit and 64bit windows, passing a pointer of a specific size (seriously, I am guessing a little, I haven't written winapi code in a long while).

To be fair, if fbc was actually being strict about the type checking it would error and abort the compile. Clearly, it's not doing that. Warnings only to indicate that, maybe should have another look.
----
What basic are we comparing to? Maybe it is VB5/6? It accepts just about anything; does that mean it is automatically good for beginners? I don't know. In VB5/6, with WINAPI declare BYVAL/BYREF as ANY, AddressOf, BYVAL arg, undocumented VarPtr(); I think the programmer really needs to understand the WINAPI and how VB works with data types to make WINAPI calls work. Usually, the only indication that the programmer go it wrong is "Bad DLL call" or some such message (sorry, I can't remember the exact message when the VB application crashes)

For example, SendMessage() with 4th param (LPARAM) as pointer or scalar depending on context:

Code: Select all

 
'' In VB5/6
Option Explicit

'' multiple declares for same WINAPI
Declare Function SendMessagePTR Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
Declare Function SendMessageNONPTR Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Any) As Long
Declare Function SendMessageFUNCPTR Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long

'' undocumented
Declare Function VarPtr Lib "msvbvm60.dll" (Var As Any) As Long

Sub proc()
End Sub

Sub Main()
    
    Dim a As String
    Dim b As Long

    SendMessagePTR 0, 0, 0, 0
    SendMessagePTR 0, 0, 0, ByVal 0
    
    SendMessagePTR 0, 0, 0, a
    SendMessagePTR 0, 0, 0, ByVal a
    SendMessagePTR 0, 0, 0, VarPtr(a)
    SendMessagePTR 0, 0, 0, vbNullString
    SendMessagePTR 0, 0, 0, b
    SendMessagePTR 0, 0, 0, ByVal b
    SendMessagePTR 0, 0, 0, VarPtr(b)
    SendMessagePTR 0, 0, 0, AddressOf proc
    
    '' SendMessageNONPTR 0       '' type mismatch
    '' SendMessageNONPTR ByVal 0 '' type mismatch
    
    SendMessageNONPTR 0, 0, 0, a
    SendMessageNONPTR 0, 0, 0, ByVal a
    SendMessageNONPTR 0, 0, 0, VarPtr(a)
    SendMessageNONPTR 0, 0, 0, vbNullString
    SendMessageNONPTR 0, 0, 0, b
    SendMessageNONPTR 0, 0, 0, ByVal b
    SendMessageNONPTR 0, 0, 0, VarPtr(b)
    SendMessageNONPTR 0, 0, 0, AddressOf proc

    '' SendMessageFUNCPTR 0, 0, 0, a '' type mismatch
    '' SendMessageFUNCPTR 0, 0, 0, ByVal a
    SendMessageFUNCPTR 0, 0, 0, VarPtr(a)
    '' SendMessageFUNCPTR 0, 0, 0, vbNullString
    SendMessageFUNCPTR 0, 0, 0, b
    SendMessageFUNCPTR 0, 0, 0, ByVal b
    SendMessageFUNCPTR 0, 0, 0, VarPtr(b)
    SendMessageFUNCPTR 0, 0, 0, AddressOf proc

End Sub
And VB5/6 did not directly handle pointers or function pointers directly. Only pass to a WINAPI function. In contrast, fbc, does work directly with both.
Josep Roca
Posts: 564
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

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

Post by Josep Roca »

I personally use the pedantic option because I want to be warned of all the potential errors. This makes my code more reliable and also people using it won't get warnings no matter which options use to compile it. But new users coming from VB or PowerBasic backgrounds aren't used to it, don't know how to solve it and, what is worse, they leave. I have reread the documentation for the -w option and it says "A significantly high level value will have the effect of suppressing all warning messages." Maybe we can tell them to use this option if the warnings annoy them?
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

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

Post by deltarho[1859] »

The compiler option -w in Help is very badly written.

It mentions level but does not advise on what the value of level can be other than with regard to 'all', "Equivalent to specifying a level of zero (0)".
A significantly high level value will have the effect of suppressing all warning messages.
Since we have not been given a range for level then what does "significantly high level value" mean, 3, 11, 348? <smile>
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Post by coderJeff »

Josep Roca wrote:... don't know how to solve it ...
I think you got it right there. I was actually thinking about this couple days ago, almost updating CompilerErrMsg and noticing that the error/warning identification numbers have changed for messages from one fbc version to the next.

Wouldn't it be great for users if CompilerErrMsg linked to a page for each error/warning that had:
1) example to show the warning/error
2) what it means
3) how to fix it

With almost 400 errors/warnings it would be a lot of work. LIke insane. But not impossible.
jj2007
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

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

Post by jj2007 »

coderJeff wrote:
Josep Roca wrote:The problem comes because the pfnSubclass parameter has been declared as SUBCLASSPROC

Code: Select all

declare function SetWindowSubclass(byval hWnd as HWND, byval pfnSubclass as SUBCLASSPROC, byval uIdSubclass as UINT_PTR, byval dwRefData as DWORD_PTR) as WINBOOL
SetWindowSubclass(...) is expecting a SUBCLASSPROC function pointer. Is it actually safe to give it something else instead?
Yes, that is the big question: Is it safe if we pass the scalar 123 instead of the address of a callback proc? And the answer is a clear NO, that is UNSAFE, and your code will crash mercilessly!!!

Is it safe to cross a road without a helmet and a stainless steel armour? No, that is horribly unsafe.

Folks, really, this debate is ridiculous. We are talking about BASIC, not C++. As written earlier, such strict (and confusing) type checking should not happen in a BASIC dialect. I have used such API calls since I started programming under Windows 20 years ago, and I never ever had the slightest problem with the less stricter type checking of GfaBasic or MASM. Both throw an error if
- the parameter count is incorrect
- the size of a parameter is not correct
- you pass an integer instead of a float or double (and vice versa, of course)

Otherwise both Masm and GfaBasic assume that you are able to read MSDN. I can't imagine that this shouldn't work with FreeBasic. Sending a beginner in circles with monsters like OldWinProc = CAST(ANY PTR, SetWindowLongPtr(Edit_1, GWLP_WNDPROC, CAST(LONG_PTR, @SubEdit))) is sick, and definitely not the right thing for a Beginners All purpose Symbolic Instruction Code.

> The problem comes because the pfnSubclass parameter has been declared as SUBCLASSPROC
I fully agree, that is the problem. It should never have been declared as "SUBCLASSPROC" or "MyFavouriteExoticNewType". It is a POINTER. A POINTER is some variable POINTING to some other item, in this particular case: obviously a POINT in memory where a callback procedure starts, typically with a push ebp. So all the compiler needs to know is that the size of that POINTER is 64 bits in 64-bit code, and 32 bits in 32-bits. If you pass a QWORD-sized variable in 32-bit code, or a double, then, and ONLY then, the compiler should bark at you.

Btw, I find it hilarious that the compiler doesn't know what to do with

Code: Select all

SendMessageW(hStatic, WM_SETTEXT, 0, "ok")
Again, it's nonsense to force a beginner to consult Google or to guess the meaning of the FB manual in order to finally arrive at

Code: Select all

SendMessageW(hStatic, WM_SETTEXT, 0, StrPtr("ok"))
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Post by coderJeff »

What is hilarious is that I spend all my free time for the last 12 months to understand fbc and improve it. And a year ago this post: What to about the lack of developers for the compiler?

This message board has a "secret" Developers Forum, where the developers used to talk about upcoming changes. Well, about 3 years ago, we had a short discussion where we all agreed that we should just have the same discussions on the forums, for everybody, in the hopes that more members would become involved.

So, without a doubt, for last 3 years, any fbc development has been 100% in public view on fb.net, sourceforge.net, & github.

What you are seeing in this topic, right here, is the kind of discussion that the developers would have. The most significant difference from developers only discussion is that if there is a dispute or disagreement over the direction that the project is taking, there is always a solution offered as well.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Post by coderJeff »

deltarho[1859] wrote:
coderJeff wrote:the only way to make fbc quiet, is either to disable warnings completely, or cast to any ptr.
That is not strictly true. One application which uses José Roca's WinFBX saw two inc files with issues, either 'Return type mismatch' or 'Argument count mismatch'. When I used 'Integer Ptr', as opposed to 'Any Ptr', I got no warnings at all and the application compiled and ran successfully in both 32 and 64 bit.
Yes, this deserves further explanation: The new warnings are for function pointer to function pointer conversions only.
a CAST to ANY PTR should drop all type checking. If it's not, then probably have to revist that part of the compiler. And CAST from function ptr to INTEGER should work like in C. Not trying to change everything here. The end goal is having a reliable CONST check, for those that are interested in that sort of thing; there are a number of situations in fbc 1.05 where the CONSTness of data is just lost or ignored, and some programmer would consider that a bad thing.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Post by coderJeff »

MrSwiss wrote:@Admin, coderJeff,

while you are busy on the 'Const(ness)' issue, please keep in mind:
#823 Overloaded Function with Array() "as Const ..." Parameter = Error)
since it seems to be related (at least).
Dang it! I though I found them all, I guess I missed that one. Yea, currently, the overload resolution for arrays succeed only if an exact match. I can see that it would be useful to pass non-const array to const array. I recently changed the overload resolution to give better what I think are better results, i.e. more unique matches. The type checking to resolve const arrays needs to be expanded to fix this bug.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Post by coderJeff »

jj2007 wrote:On Windows, most of the warnings are just confusing. Those related to API calls should be off by default.
How could we do this? Seriously, do you have any ideas? From fbc's point of view it doesn't really know the difference between an API call and some other function. Linux users won't care about this, so it would WINAPI specific.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Post by coderJeff »

Josep Roca wrote:I personally use the pedantic option because I want to be warned of all the potential errors. ... -w option and it says "A significantly high level value will have the effect of suppressing all warning messages." Maybe we can tell them to use this option if the warnings annoy them?
This makes sense to me. Like, we could just disable warnings in the default compilation, but is that what we really want to do? For example, actually, rank the warnings in order of severity, and have the compiler only report the more severe ones by default. Keep in mind though, the warnings don't actually prevent the exe from being compiled.

IDE's add another level to this. Even though fbc might have a default option, the IDE writer could make the default warning level something else.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Post by coderJeff »

fxm wrote:Normally, a relevant code (I think) does not produce any warning, especially after having apply the right syntax of operator Cast/Cptr if necessary.
That's why I'm still wondering if the compilation options 'constins' and 'funcptr' should not be added to the list of current options enabled by the 'pedantic' compilation option.
I think we need to take small steps here that lead us to the goal.

In https://github.com/freebasic/fbc/pull/94 I've made new changes. dkl was kind enough to offer comments on the first try I made, so I will wait a few days to see what he has to say about the revised update.

Here's what I have in mind:
- the new checks occur internally, always; this is required to fix some bugs
- by default, no new warnings are generated by CAST()/CPTR()
- by default, implicit function conversion may get an additional warning. So, where fbc might have generated "Suspicious Pointer Assignment", an addition warning may also be generated describing the reason.
- '-w funcptr' will check function pointer to function pointer conversions even in CAST()/CPTR(). This is not included in '-w pedantic'
- '-w constness', implies '-w funcptr', and will check CONST conversions and warn if CONST has been discarded

I think this is the starting point. For average user and '-w pedantic' user they might see new warning messages where they are already getting warning messages.
Post Reply