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 »

coderJeff wrote:
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.
Perhaps by checking for the type WINAPI? The C/C++ header files are full of them:

Code: Select all

WINAPI
ExitProcess(
    __in UINT uExitCode
    );
The point here is that MSDN is very detailed about the arguments to be passed. Example CreateWindowEx:

Code: Select all

HWND CreateWindowExA(
  DWORD     dwExStyle,
  LPCSTR    lpClassName,
  LPCSTR    lpWindowName,
  DWORD     dwStyle,
  int       X,
  int       Y,
  int       nWidth,
  int       nHeight,
  HWND      hWndParent,
  HMENU     hMenu,
  HINSTANCE hInstance,
  LPVOID    lpParam
);
That is the top level; it is followed by, for example:
Type: HMENU
A handle to a menu, or specifies a child-window identifier, depending on the window style. For an overlapped or pop-up window, hMenu identifies the menu to be used with the window; it can be NULL if the class menu is to be used. For a child window, hMenu specifies the child-window identifier, an integer value used by a dialog box control to notify its parent about events.
Now, as a Masm or GfaBasic programmer, I read the doc and make sure that I don't pass real nonsense to CreateWindowEx. But I would never bother to create a menu (in the case of the parent window) with the "correct" HMENU type. It's a DWORD, fullstop. See what happens with no w level set:

Code: Select all

	hStatic=CreateWindowEx(0, "static", "start typing now...",_
	WS_CHILD Or WS_VISIBLE, 3, 1, 285, 20, hWnd, 100, 0, 0)

Code: Select all

C:\AllBasics\FreeBasic\tmp\TmpFile.bas(109) warning 1(1): Passing scalar as pointer, at parameter 10 of CREATEWINDOWEX()
CAN YOU SEE THE FAT MISTAKE AT PARAMETER 10? NO?
This is extremely messy, but it compiles just fine. And FB "knows", somehow, magically, that "start typing now..." in this context should be translated as a pointer to a zero-delimited string. Instead, when you try the very similar SendMessageW(hStatic, WM_SETTEXT, 0, "ok"), it throws an error, and the only way to fix it is spending some time with Google, do a lot of trial and error, and finally arrive at this awkward construct: SendMessageW(hStatic, WM_SETTEXT, 0, StrPtr("ok")) - which is NOT required for the strings in MessageBox(...). All this is utterly confusing, and puts me off as an experienced programmer. If I was a newbie, I would run away as fast as I could.

The obsession with types is C/C++, not BASIC. Every time I boot my machine, Adobe asks me to install a new, better and safer version. I am sure there are "professional" programmers at work, but they are probably hypnotised by endless pages of obscure type check warnings. Maybe one day they would deliver a really safe product if the Adobe CEO forced them to work in QBASIC...

So, my constructive recommendations:
- if FB discovers a WINAPI, let it be tolerant (unless user expresses explicitly an urgent desire to check everything, e.g. as -w torture)
- if FB discovers a WINAPI, let it translate quoted strings to zstring pointers,
badidea
Posts: 2586
Joined: May 24, 2007 22:10
Location: The Netherlands

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

Post by badidea »

To change the compiler behaviour based on if certain libraries are included not, does not seem like the best approach to me.

If I see function calls that looks like:

HWND CreateWindowExA(DWORD dwExStyle, LPCSTR lpClassName, LPCSTR lpWindowName, DWORD dwStyle, int X, int Y, int nWidth, int nHeight, HWND hWndParent, HMENU hMenu, HINSTANCE hInstance, LPVOID lpParam)

That does not look very beginner friendly anyway.
Maybe freebasic needs a wrapper for (a part of) the WINAPI to hide all this ugly stuff?
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 think that the compiler should provide the current checking options, but provide a -w none option to supress all warnings for those that don't want them.

Maybe it will happen like those not wanting to have to declare a variable before using it that with time end using DIM ALL. After many GPFs because using wrong pointers, maybe they will begin to appreciate the compiler checks.
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] »

jj2007 wrote:It's a DWORD, fullstop.
That is how PowerBASIC works. If I wrote an application to scan my PowerBASIC development folder for the most used word it would be DWORD.

Code: Select all

FreeBASIC

declare function CreateWindowExA
    (byval dwExStyle as DWORD, byval lpClassName as LPCSTR, _
    byval lpWindowName as LPCSTR, byval dwStyle as DWORD, byval X as long, _ 
    byval Y as long, byval nWidth as long, byval nHeight as long, _
    byval hWndParent as HWND, byval hMenu as HMENU, _
    byval hInstance as HINSTANCE, byval lpParam as LPVOID) as HWND
    
PowerBASIC

DECLARE FUNCTION CreateWindowExA LIB "User32.dll" ALIAS "CreateWindowExA" _
    (BYVAL dwExStyle AS DWORD, lpClassName AS ASCIIZ, _
    lpWindowName AS ASCIIZ, BYVAL dwStyle AS DWORD, BYVAL x AS LONG, _
    BYVAL y AS LONG, BYVAL nWidth AS LONG, BYVAL nHeight AS LONG, _
    BYVAL hWndParent AS DWORD, BYVAL hMenu AS DWORD, _
    BYVAL hInstance AS DWORD, lpParam AS ANY) AS DWORD
Oh, look ma, no HWND, no HMENU and no HINSTANCE in PowerBASIC - they are all DWORDs in PowerBASIC.
Why is that sonny?
Well, because they are all DWORDS, ma.
I figured that out, now go and put the kettle on.
Yes, ma.
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:After many GPFs because using wrong pointers, maybe they will begin to appreciate the compiler checks.
jj2007 wrote:Is it safe to cross a road without a helmet and a stainless steel armour? No, that is horribly unsafe.
The difference is that in a road accident, you get killed. With a GPF, my JIT debugger shows me where the problem sits. And you must be pretty dumb, or totally hypnotised by endless flows of useless warnings, to pass an invalid pointer to a WINAPI. Output from the simple 172 lines subclass example in the other thread:

Code: Select all

C:\AllBasics\FreeBasic\tmp\TmpFile.bas(39) warning 2(1): Passing pointer to scalar, at parameter 4 of SENDMESSAGEW()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(50) warning 2(1): Passing pointer to scalar, at parameter 4 of SENDMESSAGEW()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(79) warning 2(1): Passing pointer to scalar, at parameter 4 of SENDMESSAGEW()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(95) warning 2(1): Passing pointer to scalar, at parameter 4 of SENDMESSAGEA()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(107) warning 1(1): Passing scalar as pointer, at parameter 1 of SETTEXTCOLOR()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(108) warning 1(1): Passing scalar as pointer, at parameter 1 of SETBKMODE()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(112) warning 5(0): Implicit conversion
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(116) warning 1(1): Passing scalar as pointer, at parameter 10 of CREATEWINDOWEX()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(118) warning 1(1): Passing scalar as pointer, at parameter 10 of CREATEWINDOWEX()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(125) warning 1(1): Passing scalar as pointer, at parameter 10 of CREATEWINDOWEX()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(126) warning 2(1): Passing pointer to scalar, at parameter 3 of SETWINDOWLONGPTR()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(126) warning 4(1): Suspicious pointer assignment
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(128) warning 1(1): Passing scalar as pointer, at parameter 10 of CREATEWINDOWEX()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(129) warning 2(1): Passing pointer to scalar, at parameter 3 of SETWINDOWLONGPTR()
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(129) warning 4(1): Suspicious pointer assignment
C:\AllBasics\FreeBasic\tmp\TmpFile.bas(145) warning 4(1): Suspicious pointer assignment
No GPF, ma. How will it look like if you have a real project with, say, 20,000 lines? How will that source look like if, after replacing all "bad" code with monsters like monsters like OldWinProc = CAST(ANY PTR, SetWindowLongPtr(Edit_1, GWLP_WNDPROC, CAST(LONG_PTR, @SubEdit))), you finally don't see any warning?
Last edited by jj2007 on Sep 02, 2018 11:44, edited 1 time in total.
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 »

> Oh, look ma, no HWND, no HMENU and no HINSTANCE in PowerBASIC - they are all DWORDs in PowerBASIC.

But with a 64 bit compiler they arent DWORDs. If some day PB comes with a 64 bit compiler, PBers will have a very hard time to adapt their existing code.
dafhi
Posts: 1641
Joined: Jun 04, 2005 9:51

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

Post by dafhi »

It's good to see someone with some actual technical knowledge explain this.
suspicious ptr warnings are like training wheels that never come off
Last edited by dafhi on Sep 02, 2018 13:27, edited 3 times in total.
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:But with a 64 bit compiler they arent DWORDs.
That is correct. Therefore, FB should know and check a pointer type. ONE pointer type. And it shouldn't complain if you pass a "0" instead of a pointer variable (Windows knows what to do with a zero where a pointer is expected). But if you pass a 32-bit variable in 64-bit code where a pointer is expected, then the compiler should not issue a warning, it should throw an error.
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 »

As I said, my suggestion is to add the -w none option. If used, the compiler won't issue any warning.
St_W
Posts: 1619
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

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

Post by St_W »

coderJeff wrote: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.
IIRC the page's error/warning messages are automatically extracted from fbc source code, so you probably shouldn't change those parts of that page manually.

I don't think that the result of this discussion should be to remove most of the type error checking that fbc currently has, as most of it is fine.
We should collect the few cases where the default type checks are considered too strict by the majority (e.g. like the scalar <-> ptr case José has mentioned) and try to find solutions for those. Instead of simply dropping warning messages (or providing a compiler option to do so) I'd favor a syntax that allows declaring method paramters where both scalar and ptr values are allowed and thus no warning is issued. Maybe some kind of annotations as known from other programming languages.
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

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

Post by dodicat »

jj2007
Maybe you know this.
Compile with -pp switch

Code: Select all

#include "windows.bi" 
Will give quick access to many api keywords (With a good ide of course I use fbide)
Also 0 should be accepted as a pointer.
Example

Code: Select all

screen 19
sub drawline(i as any ptr=0)
    line  i,(20,20)-(200,200)
end sub

drawline

dim as any ptr i=imagecreate(200,200)

drawline(i)
put(300,300),i,pset
sleep
imagedestroy i

 
Also HMENU is a pointer.

... from the above windows.pp.bas file ...
type HMENU__
unused as long
end type

type HMENU as HMENU__ ptr
...

But seems (for createwindowex) to be doomed to the value 0 anyway

Code: Select all

   
   
   #include "windows.bi"
   function dummy(hWnd As HWND, msg As UINT, wParam As WPARAM, lParam As LPARAM) As LRESULT
       select case msg
        Case WM_DESTROY
      PostQuitMessage(0) 
      end
     End Select
    return DefWindowProc(hwnd, msg, wParam, lParam)
   end function
   
   
   
   Dim As WNDCLASSEX wc
   dim hInstance As HINSTANCE
   wc.cbSize = sizeof(WNDCLASSEX)
   wc.hbrBackground = GetStockObject(BLACK_BRUSH)'COLOR_BTNFACE+1
   wc.hCursor = LoadCursor(0, IDC_ARROW)
   wc.hIcon = LoadIcon(hInstance, IDI_APPLICATION)
   wc.hIconSm = wc.hIcon
   wc.hInstance = hInstance
   wc.lpfnWndProc = @dummy
   wc.lpszClassName = StrPtr("hi")
   wc.style = CS_HREDRAW Or CS_VREDRAW
  if RegisterClassEx(@wc)=0 then print "bye":sleep: end
   
   #print typeof(HMENU)
   dim as HMENU HMEN
   'HMEN=new HMENU__  'doesn't work
   'HMEN->unused=101
   var win = CreateWindowEx(0, wc.lpszClassName, "Simple subclassing example",_
   WS_OVERLAPPED or WS_CAPTION or WS_SYSMENU or WS_MINIMIZEBOX or WS_VISIBLE,_
   (GetSystemMetrics(SM_CXSCREEN) / 2) - 150,_
   (GetSystemMetrics(SM_CYSCREEN) / 2) - 100, 300, 140, 0, HMEN, hInstance, 0)
   
     if win=0 then
          MessageBox(0, "Creating hMain failed miserably", 0, MB_OK)
          end
      end if
    dim as msg msg
    
      While GetMessage(@msg,0, 0, 0)
      TranslateMessage(@msg)
      DispatchMessage(@msg)
      Wend
   
The winapi headers for 64 bit are really in the testing stage.
member dKL asked others to report any singularities (Maybe too strong a word)
But since the development has stalled I think many folk have lost some interest.
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:As I said, my suggestion is to add the -w none option. If used, the compiler won't issue any warning.
I don't agree. Warnings have a function: They warn the programmer that there might be a problem. It is when a tiny GUI example produces a whole page of warnings that the concept fails miserably. What happens if your code is 20,000 lines instead of only 172? You get literally dumped with useless stuff, and just in case two or three useful warnings are inside this garbage, nobody will be able to identify 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] »

Josep Roca wrote:But with a 64 bit compiler they arent DWORDs.
That did not cross my mind, clearly.

I tinker with 64 bit but never release anything in 64 bit. I don't write anything which ticks a 64 bit box hence I tend to be in 32 bit mode myself.

We could use UINTEGER in this situation. I have a bucket of water ready in case I get 'flamed' on that one. <smile>"
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 »

dodicat wrote:Compile with -pp switch
Produces a 1.4 MB file full of declarations. What would be needed is a compiler that issues warnings where they really make sense...
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 »

St_W wrote:IIRC the page's error/warning messages are automatically extracted from fbc source code, so you probably shouldn't change those parts of that page manually.
Yes, thanks. I was going to update the page with the auto tool, and was thinking I could automatically generate links to pages that describe each warning in more detail.
Post Reply