
Two musings on the design of compiler warnings - ingve
https://quuxplusone.github.io/blog/2020/09/02/wparentheses/
======
PaulHoule
There is a set of concerns in this article that are universal, and then there
are the specifics of C, which generally leave me horrified that because some
rando is free to write

    
    
      if((this=that)) {
        ...
      }
    

some hackers can crash the power grid, blow up a chemical plant, etc. Using
the double paren to suppress warnings is frankly terrifying to me because the
double paren is the kind of thing that comes out of the ten thousand monkeys
that almost understand Noam Chomsky that are trying to 'help' me in my IDE or
when I type with a touchscreen -- the same accidents that might result in
"this=that" could just as well leave double parens...

OTOH in more civilized languages the question of error messages is fascinating
to me but insufficiently documented, in fact it is part of the "parser
generators haven't improved since yacc" syndrome. "Little languages" like the
ones yacc was invented to make easy haven't taken off in the way that yacc's
siblings did because of a handful of problems that haven't been addressed in
one tool -- and the error handling is the worst of them.

I told the Jena people that I thought error handling with their RETE engine
was great -- I could look at the error and look at the Jena source code and
understand what was wrong with my source code. That was just not the case with
Drools.

~~~
saagarjha
See, I think your problem is specifically with the fact that C provides the
same operator for "assignment" and "assignment and I get a value back". The
issue is that the latter is useful but generally not what you want, so this is
why we warn about it but I don't think it's justified to be horrified about
it.

------
Aardwolf
unused variable is the warning that causes me the most pain

it happens so often that I want to test or debug something, disable some code,
or replace some value by "5" or what not as a placeholder, and then get the
unused variable warning

sure, it can be fixed with (void) casts, but sometimes there are multiple
unused variables due to commenting out part of code, then you have to hunt all
of them

and sure it can be fixed with a flag to disable this warning, but that may
require a recompile of everything if the build system considers this a change
of compiler flags

and sure you could disable it always, or only for certain modes, but the
warning also has its merits

~~~
throwaway43234
Or just ignore warnings if you know they're from a temporary change that wont
ever be committed?

~~~
quicklime
Some teams turn on the switch in their compiler or linter that turns warnings
into errors. Not many people invoke their compilers directly anymore, so
disabling this requires digging into the build system configuration, which is
not always simple (and as the OP mentioned, can require a full rebuild).

Sometimes this is even baked into the language itself. For example Go can be
strict about unused imports and variables. Python is strict about having
correct indentation.

~~~
marcosdumay
> Some teams turn on the switch in their compiler or linter that turns
> warnings into errors.

That's completely self-inflicted. I really don't get why people do that
instead of just fixing the warnings... except if one is in some position of
power over environment configuration, but not over work results. Even then,
why does that person care about work results?

~~~
beojan
In large bodies of code, you might not notice the warnings if they weren't
errors.

~~~
kazinator
Code size can have something to do with it, but less than you think.

Basically, you don't notice warnings because you choose not to look.

Firstly, no matter how large the program is, if it builds without warnings and
then a change is introduced which triggers a warning, it will be noticed. You
only don't notice a new, potentially important warning when it is drowned out
by "nuisance" warnings that you stopped caring about months or years ago. This
tends to be a problem in larger programs worked on by many people, but it
could easily affect a small, solo-effort program as well.

You perhaps don't notice warnings because the build log is too long to read,
and you haven't put in CI process which scans logs for warnings and produces
feedback. When you build locally, you don't bother using an IDE which picks up
all the errors and warnings out of the build output an lets you navigate
through them. This can be a problem when people don't build locally; they just
throw the code into some remote build system and if it goes "green", they
"ship it".

------
m463
I remember very old versions of lint had hints you could add, like:

    
    
       /*NOTREACHED*/
    

that would suppress warnings. I kind of liked that method.

