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

[fxm]

How will be organized the warning levels?

I proposed as below:

Syntax
-w level | all | param | escape | pedantic | next | constness | funcptr

Parameters
- level
Warning messages only with a level equal or greater to this value will be output.
- all
Equivalent to specifying a level of zero (0).
- param
Warn when procedure parameters aren't specified with either ByVal or ByRef.
- Escape
Warn when string literals contain any number of escape characters (\).
- pedantic
Equivalent to specifying the param, Escape and funcptr arguments, plus length checking of parameters passed ByVal and of any CPtr converting to pointer only.
- Next
Warn when Next is followed by an identifier.
- constness
Warn when CONST (Qualifier) is discarded in an assignment.
- funcptr
Warn on function pointer assignment incompatibilities.

Description
The -w compiler option determines which compiler warnings, if any, are output. Each possible warning is associated with a warning level, starting from zero (0) and increasing with the potential problems that may occur. A significantly high level value will have the effect of suppressing all warning messages.

Note that the param, Escape, pedantic, Next, constness and funcptr arguments provide additional warnings not ordinarily output, even by default.

If the -w option is not specified, it's as if -w 0 was used. The -w option can be specified multiple times.

[jj2007]

On Windows, most of the warnings are just confusing. Those related to API calls should be off by default.

[St_W]

re documentation: Also "-w constness" seems to be absent from the list.

re compiler warnings for cast: I'm not even sure whether CAST should generate a warning if constness is casted away (I don't know for sure without trying it out, butI think C wouldn't generate a warning in that case, would it?). But anyway my comments were just intended as a small contribution to this discussion. Language design is not easy and there's no binary "right" or "wrong".

[fxm]

re documentation: Also "-w constness" seems to be absent from the list.

Yes, but I have not understood how it works.
Can you provide an example?

[coderJeff]

'-w <level>' has been an option since at least fbc ver 0.14
most warnings are level 0

Code: Select all

a.bas(5) warning 5(0): Implicit conversion
-------------------^                       
level=0

Added only since Aug 20, 2018, '-w constness', an example:

Code: Select all

dim x as const integer = 1

scope
	dim p as const integer ptr = @x '' OK
	p = @x                          '' OK
end scope

scope
	dim p as const integer ptr = cast( integer ptr, @x ) '' unsafe
	p = cast( integer ptr, @x )                          '' unsafe
end scope

scope
	dim p as const integer ptr = cast( const integer ptr, @x ) '' OK
	p = cast( const integer ptr, @x )                          '' OK
end scope

scope
	dim p as integer ptr = cast( integer ptr, @x )  '' unsafe
	p = cast( integer ptr, @x )                     '' unsafe
end scope

The full test I wrote:
https://sourceforge.net/p/fbc/code/ci/m ... iscard.bas
https://github.com/freebasic/fbc/blob/m ... iscard.bas

[fxm]

Thanks a lot!

But now another question:
should 'funcptr' be included in 'pedantic' level?
Currently this is not the case for 'constness':
but I always wonder what is the rule we should apply for 'constness' and 'funcptr' ?

[fxm]

re documentation: Also "-w constness" seems to be absent from the list.

Done:
- CompilerCmdLine → fxm [Added '-w constness' compiler option]
- CompilerOptw → fxm [Added '-w constness' compiler option]
- KeyPgPragma → fxm [Added '-w constness' compiler option]

[coderJeff]

Bear in mind were discussing the development version: I am working on trying to find a reasonable fix, that keeps the type checking, but optionally.

should 'funcptr' be included in 'pedantic' level?

Currently, in fbc 1.06 August, fbc acts like '-w funcptr' is always on. That's a problem; the only way to make fbc quiet, is either to disable warnings completely, or cast to any ptr. Neither of which seem sensible. If we move it to '-w pedantic' then we just have the same problem there.

Thanks, for updating the wiki. I generally don't like #pragma's, but in this case, it made testing much easier. I wouldn't rely on it in normal code. Still it's good to have it in the wiki, because it does currently exist in fbc. Thanks.

[deltarho[1859]]

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.

[Josep Roca]

I have fixed these issues by changing the return type from LRESULT to LONG and the pWndProc from WNDCLASSPROC to SUBCLASSPROC. The issue with the return type was my mistake and I'm glad that the compiler now detects it. The other... Well, sometimes you can need to pass a pointer that, depending od other factors, may point to different things, for example to a Window procedure or to a subclass procedure. If I have to use ANY PTR, so be it, but I think that if I cast a WNDCLASSPROC pointer to a SUBCLASSPROC pointer, the evaluation should be done taking into account the conversion, i.e. with SUBCLASSPROC and not with the original WNDCLASSPROC declaration.

[MrSwiss]

@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).

[fxm]

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.

[coderJeff]

Well, sometimes you can need to pass a pointer that, depending od other factors, may point to different things, for example to a Window procedure or to a subclass procedure.

That seems like it should be an ANY PTR. A pointer that could be pointing to multiple things. Everything I read commctrl subclass API functions seems to indicate that WNDPROC (4 parameters) and a SUBCLASSPROC(6 parameters) are not interchangeable.
https://docs.microsoft.com/en-us/window ... g-overview

The declaration of a subclass procedure is slightly different from a regular window procedure because it has two additional pieces of data: the subclass ID and the reference data. The last two parameters of the following function declaration show this.

[jj2007]

cast a WNDCLASSPROC pointer to a SUBCLASSPROC pointer, the evaluation should be done taking into account the conversion, i.e. with SUBCLASSPROC and not with the original WNDCLASSPROC declaration.

Can you explain the difference between a WNDCLASSPROC and a SUBCLASSPROC, technically speaking? Maybe in Petzold's terminology?

[Josep Roca]

Sorry, I mean WNDPROC, not WNDCLASSPROC.

The difference is that one uses this declaration

type WNDPROC as function(byval as HWND, byval as UINT, byval as WPARAM, byval as LPARAM) as LRESULT

and the other

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

You're using the old style for subclassing, with SetWindowLong, but my CWindow class also offers the option of use the more modern SetWindowSubclass function.

BTW in Petzold's times SetWindowSubClass did not exist yet.