Compiler option: -w

[Juergen Kuehlwein]

There is a bug in this page

...
all
Equivalent to specifying a level of zero (0).
...

This is not true, "all" specifies a level of -1.


JK

[fxm]

What documentation version do you use?
This was corrected on 2018-09-03.
(FB-manual-1.06.0 is OK, and obviously the wiki too)

[counting_pine]

Thanks for the report.
Note: the documentation files are produced from the FreeBASIC Wiki. This particular page is at CompilerOptw.
From the history, it looks like Jeff corrected this last year.

[Juergen Kuehlwein]

Obviously i have an outdated offline version (.chm) of the manual. Sorry for bothering you :-(


JK

[fxm]

A 'freebasic_manual.chm' built every time the wiki is updated.
See at: http://users.freebasic-portal.de/stw/builds/

[Juergen Kuehlwein]

Thanks, i already had it, but i made a mistake linking it to my IDE. So the older one was used instead of the new one, and i didn´t even notice it - my bad.


JK

[coderJeff]

Cosmetically, it would be nice to rebase the warning numbers to zero. It would change the meaning of '-w' option and numbers of warnings, but output would look nicer.

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

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.

[Roland Chastain]

Hello!

Maybe not very important, but I discovered that if I use an invalid value for the -w switch, the compiler doesn't complain.

fbc -w fantastic myfile.bas

Test made with FBC 1.07.1 for Linux 64.

[coderJeff]

Thanks, I added this statement to Compiler Option: -w

fbc does not issue warning or error if the warning name itself is not valid. For example -w flarg, is not a recognized name for a warning. The compiler silently ignores this to allow command lines with warnings added in new versions of fbc to also be used with older versions of fbc without complaint.

Behaviour since at least version 0.14.

[jj2007]

Sheer luxury would be an option to disable the silly warnings with SendMessage & friends

[coderJeff]

Sheer luxury would be an option to disable the silly warnings with SendMessage & friends

-w none, or a significantly high level value will have the effect of suppressing all warning messages

For example fbc -w none TmpFb.bas as in viewtopic.php?p=274595#p274585

[jj2007]

Sheer luxury would be an option to disable the silly warnings with SendMessage & friends

-w none, or a significantly high level value will have the effect of suppressing all warning messages

For example fbc -w none TmpFb.bas as in viewtopic.php?p=274595#p274585

That suppresses all warnings, including those that make sense. It would be nice to have an option that suppresses only the silly ones of the type "you passed a string but it should have been an LPARAM"

[coderJeff]

Ah, I see. But even you jj2007 i think would agree that there's not one solution that will be desirable by everyone. The beginner user trying to learn MSDN / WinAPI and pointers would probably benefit from the warnings so they at least understand what's expected. And for veteran programmers like yourself the warnings simply do not matter and get in the way.

Here's what I think we can do:
1) re-evaluate the warning level of all the warnings, so for course grain control the '-w level' can provide some filtering
2) update the docs to show the warning # + level #, which is currently not shown.
3) add something like '#pragma push warn(number), value' and friends to allow personalized suppression of warnings and fine gain control.
4) allow command line '-w ...whatever...' to override the pragma's.

fbc is starting to get a lot of command line options like gcc, which I don't think is all that desirable either. We want to make good default decisions for the benefit of the user, but there are users that may want to have a more personalized usage / expression of their code. Not an easy decision at times.

Furthermore, we haven't paid much attention to the actual warning number (or error number) in any fbc version. The number values tend to change from version to version without any concern. It would be nice to lock down the numbering of warnings and errors so that it would be possible to create manual pages for specific warning numbers and error numbers that have examples and possible advice to correct.

[jj2007]

The beginner user trying to learn MSDN / WinAPI and pointers would probably benefit from the warnings so they at least understand what's expected. And for veteran programmers like yourself the warnings simply do not matter and get in the way

We had that discussion two years ago:

If 10% of your lines in a simple (and correctly working) Windows GUI program get criticised with warnings, then there is definitely a problem to solve.

The point is that certain Windows calls, in particular SendMessage, are not compatible with the way the compiler works. SendMessage wants integers, singles, pointers, handles - the compiler believes it needs exclusively a WPARAM and an LPARAM. The result is absolutely useless warnings.

And no, the n00b does not benefit from these warnings, the n00b gets scared away of FB because of them!

The expert who writes 1000 lines programs gets drowned in an endless flow of warnings and will therefore not see the one warning that really makes trouble. I have a source with 300 SendMessage calls. And don't tell me that casting integers, singles, pointers, handles to WPARAM is a "solution"...

[coderJeff]

We had that discussion two years ago:

I didn't forget. Nor this from a year ago

I do not have any stakes here. I have my own Basic dialect, definitely not meant for public use (it's assembler), and I don't need FB.

You seem quite knowledgeable and active on the forums. Some of your criticisms of freebasic are worth investigating. Honestly, I was kind of expecting (maybe just hoping) for a different kind of interaction. My mistake.