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

[coderJeff]

I think it fair to consider the proposal of changing the default warnings a separate matter from this update. The warnings shown by default hasn't changed in 10+ years. This is something new.

On one extreme, there are users like myself that prefer to work directly with the abstract types, and find the warning messages meaningful, so the code can be altered to express more explicitly.

On the other extreme, there are users that prefer to work with the underlying concrete type directly, find the warning messages meaningless, as there is no need to alter code that works.

I am confident that this group here will never reach a consensus as to preferring one extreme or the other. So it's really a matter of what is acceptable of when fbc will notify about the type discrepancies, because either way, internally, fbc does the type checking. Without it, fbc can't work. I can't say what is best for a beginner BASIC programmer dealing with pointers and MSDN (written in C). But if that is one of the goals, then first step is to evaluate each warning if it is meaningful to show by default or not. Placing each warning in the 'default' category or '-w all' category.

[coderJeff]

Merged to fbc/master in git:

- added '-w none' option to suppress warnings. 'none' is based on warning level and is a better way of saying '-w <level>' where level has sufficiently high value to suppress warnings...etc
- warnings generated by default now are same again as fbc 1.05/pre-August 1.06
- warnings generated with '-w pedantic' now are same again as fbc 1.05/pre-August 1.06
- '-w all' will show the additional function pointer warnings
- '-w funcptr' implies '-w all' and will show function pointer warnings, inside CAST()/CPTR() also
- '-w constness' implies '-w funcptr' and will show const discarded warnings

So at the very least, now, in this most recent update, there are no new warnings generated by default compared to fbc 1.05/pre-August 1.06, and for those that are interested, there's a couple new warning options to play with to check source code.

One thing I would still like to fix, is that internally, '-w all' is actually equivalent to '-w -1'. That is, internally the warning level goes from -1 to 2 with the default level=0. I'd like to change that to 0 to 3 with the default level=1. What does that mean for users? well if they were using '-w level' in their builds, they would need to increment the level by 1 to get the same results.

[fxm]

So, if I want to display all the warnings, except those of the "next" test, I have to compile with: "-w pedantic -w constness" ?

[jj2007]

On one extreme, there are users like myself that prefer to work directly with the abstract types, and find the warning messages meaningful, so the code can be altered to express more explicitly.

On the other extreme, there are users that prefer to work with the underlying concrete type directly, find the warning messages meaningless, as there is no need to alter code that works.

The main issue here is the way Windows works. Warnings are good if they prevent the coder from doing risky things that do not necessarily result in crashes. But they quickly get useless if the coder gets flooded with warnings. Here is a simple example:

Code: Select all

' SendMessageW(hStatic, WM_SETTEXT, 0, "ok")	' error 57: Type mismatch, at parameter 4 of SENDMESSAGEW()
SendMessageW(hStatic, WM_SETTEXT, 0, StrPtr("ok"))	' warning 2(1): Passing pointer to scalar, at parameter 4 of SENDMESSAGEW()

The "ok" should work, but it doesn't; the workaround does exactly what Windows expects, i.e. it passes a pointer to a zero-delimited string. But the poor coder gets a warning that this is not right. In my subclassing example, 10% of all lines get a warning. With a lot of work and trial and error, I might be able to eliminate some of them by performing casting acrobatics, but this is clearly not the way any BASIC dialect should work. And afaik, there are no other non-Basic languages that behave like this. Therefore my proposal to check if it's a WINAPI, and if yes, to relax and let pass whatever the coder believes should pass. For the masochists, you can leave a -w strict or whatever option to disable the relaxed behaviour.

[fxm]

Code: Select all

SendMessageW(hStatic, WM_SETTEXT, 0, "ok")	' error 57: Type mismatch, at parameter 4 of SENDMESSAGEW()

The "ok" should work, but it doesn't;

No, the procedure expects a "LONG/LONGINT" (32-bit/64-bit) parameter and you provide a "ZSTRING" argument !

Code: Select all

SendMessageW(hStatic, WM_SETTEXT, 0, StrPtr("ok"))	' warning 2(1): Passing pointer to scalar, at parameter 4 of SENDMESSAGEW()

the workaround does exactly what Windows expects, i.e. it passes a pointer to zero-delimited string. But poor coder gets a warning that this is not right.

No, the procedure expects a "LONG/LONGINT" (32-bit/64-bit) parameter and you provide a "ZSTRING PTR" argument !
(much better but not quite good yet)

[jj2007]

No, the procedure expects a "LONG/LONGINT" (32-bit/64-bit) parameter and you provide a "ZSTRING PTR" argument !

I wonder why you argue like that - just for the sake of the argument? You want to look more "professional"?

WM_SETTEXT message
Parameters
lParam
A pointer to a null-terminated string that is the window text.

What is more important, the official documentation of the message, or the rigid definition of the FreeBasic header file? This is what I call the obsession of C/C++ coders with type checking. Remember this is BASIC - if that is too difficult for you, go back to C++.

[fxm]

What does "WM_SETTEXT message" do here?

[fxm]

With FreeBASIC, we are fortunate to have a moderately typed BASIC language that dramatically reduces the appearance of obscure bugs to diagnose.
However, this typed language is not comparable to other very strongly typed languages such as ADA.

Example of lack of warnings, I was hoping better:

Code: Select all

Dim As Uinteger I = 123
Print -I
Print -1 * I
Sleep

-123
4294967173

[St_W]

@jj2007: we cannot simply implicitly convert a zstring ptr to long as it could cause a lot of mistakes for beginners. Just consider a comparison like this:

Code: Select all

if "5" < 10 then print "lower"   ' what's actually meant: if val("5") < 10 then ...

Beginners tend to do a lot of such mistakes. And FreeBasic is not JavaScript where that would just work. If you want a language without typechecking switch to JavaScript or similar languages, but FreeBasic is a statically typed language and that fundamental concept of the language cannot be simply changed.

Similarily, if you want to pass a variable of type string (FBSTRING) it cannot be implicitly converted to a scalar value. Just like you cannot pass a std::string to a function requesting a char* in C++.

btw, note that you can use @"Hello" instead of strptr("Hello") for string constants.

[jj2007]

@jj2007: we cannot simply implicitly convert a zstring ptr to long as it could cause a lot of mistakes for beginners. Just consider a comparison like this:

Code: Select all

if "5" < 10 then print "lower"   ' what's actually meant: if val("5") < 10 then ...

Right, therefore in this case FB must issue a warning or an error. But we are talking about a different case, about a message that expects as lParam "A pointer to a null-terminated string that is the window text".

Similarily, if you want to pass a variable of type string (FBSTRING) it cannot be implicitly converted to a scalar value. Just like you cannot pass a std::string to a function requesting a char* in C++.

FB is Basic, not C. And other Basic dialects do not have such problems.

btw, note that you can use @"Hello" instead of strptr("Hello") for string constants.

That's good to know, of course, but in Assembler you can use e.g. .if rv(SendMessage, hEdit, WM_SETTEXT, 0, "Hello"), and the assembler knows that "Hello" should be passed as a zstring pointer. Magic, isn't it?

I know this is very, very difficult, but the alternative is that the beginner is flooded by pages of useless and misleading warnings. Is that what you want?

[fxm]

But if a procedure has a parameter declared as " Byval Zstring Ptr ", the user can pass as argument a " Zstring Ptr " or a " Zstring [* n] " or a " String ", because compiler applyes an implicit conversion without warnings (In order to make calling the C runtime functions very easy):

Code: Select all

Sub printText (Byval p As Zstring Ptr)
  Print *p
End Sub

Dim As Zstring * 6+1 z
z = "Hello!"
printText(@z)
printText(Strptr("Hello!"))
printText(@"Hello!")  '' a string constant is always defined internally as a "Zstring * n"
printtext(z)
printText("Hello!")
Dim As String s
s = "Hello!"
printText(s)
'printText(@s)  '' warning 3(1): Passing different pointer types, at parameter 1 (p) of PRINTTEXT
'               '' and possible crash: @s provide the desciptor address for a string and not the characters address

[jj2007]

But if a procedure has a parameter declared as " Byval Zstring Ptr ", the user can pass as argument a " Zstring Ptr " or a " Zstring [* n] " or a " String ", because compiler applyes an implicit conversion without warnings

We are approaching a solution, it seems! Now the problem is that we have a) SendMessage and b) WM_SETTEXT. Micros**t is crystal clear about it:

SendMessage: Type: LPARAM - Additional message-specific information
WM_SETTEXT: lParam - A pointer to a null-terminated string

Now, as written above, it will be very, very difficult to reconcile these conflicting requirements, but if we want to avoid that newbies run away shouting in desperation, should we make an effort...? I know how do it in assembly...

[MrSwiss]

That's good to know, of course, but in Assembler you can use e.g. .if rv(SendMessage, hEdit, WM_SETTEXT, 0, "Hello"), and the assembler knows that "Hello" should be passed as a zstring pointer. Magic, isn't it?

Yes, but only with 32 bit's, if you'd code it in 64 bit's (with Inline ASM, or the like of FASM),
since MASM32 can't anyway ... MASM32 is the limiting factor, on your way of thinking, IMO.

[Josep Roca]

You can use SetWIndowText or the macro Edit_SetText.

[deltarho[1859]]

Referring to coderJeff's post beginning "Merged to fbc/master in git:".

I hope people appreciate the 'customer service' that we are getting here considering the title of this thread "Free Basic Compilers .....".

Just thought I'd mention that. <smile>