linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Mohr <andi@lisas.de>
To: linux-kernel@vger.kernel.org
Cc: Li Shaohua <shaohua.li@intel.com>, linux-acpi@vger.kernel.org
Subject: Look Ma, da kernel is b0rken
Date: Wed, 5 Dec 2012 08:09:01 +0100	[thread overview]
Message-ID: <20121205070901.GA12123@rhlx01.hs-esslingen.de> (raw)

Hi,

drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi':
drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively
exhaustive tests is always true [-Wlogical-op]
drivers/pnp/pnpacpi/core.c:66:2: warning: logical 'or' of collectively
exhaustive tests is always true [-Wlogical-op]
drivers/pnp/pnpacpi/core.c:67:2: warning: logical 'or' of collectively
exhaustive tests is always true [-Wlogical-op]


That's already the second less enticing -Wlogical-op issue
which was discovered by accident during less than two days
of my happy(?) activity of kernel suspend breakage bisection.


Why oh why, as a rather *very* critical piece of software,
can't the kernel use sufficiently aggressive warning levels *by default*??
IMHO it's simply NOT ACCEPTABLE to have such sloppiness creep into
the daily bandwagon of kernel development life
(or should I say: being mandated to creep in?).

Result: whichever default warning level you set
*will* end up as The New Normal,
and all those warnings which then remain able to rear their ugly heads
according to the chosen default level
will be fixed by the community eventually,
and *most others won't* (or at least not in time).

The amount of warnings spewn by make W=3 (or even W=2) is simply
shocking IMNSHO.
And there can always be an argument that most of such warnings
are fixable. If not directly (e.g. because analysis of that warning type
is partially unreliable), then by actively reworking code
into something slightly different.

So, unless there are very hard and *justified* reasons
for keeping builds at such lame-*ss defaults
(such as automated compliance test runs which may not fail -
but in such cases one could argue that *those* uses
should then be required to manually lessen *their* warning level settings),
I would strongly vote for having a hard discussion about the status
quo.


As a somewhat aggravating comment, please note that this warning
actually seems to date back to 1da177e (initial repository build)
according to blame on that file.

Andreas Mohr

P.S.: sorry for the subject line ;)

             reply	other threads:[~2012-12-05  7:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-05  7:09 Andreas Mohr [this message]
2012-12-05 14:29 ` Look Ma, da kernel is b0rken Borislav Petkov
2012-12-05 15:27   ` Alan Cox
2012-12-05 15:31     ` Borislav Petkov
2012-12-05 15:47       ` Alan Cox
2012-12-05 15:59         ` Borislav Petkov
2012-12-05 17:04           ` Geert Uytterhoeven
2012-12-05 17:37             ` Borislav Petkov
2012-12-05 20:57         ` Stephen Rothwell
2012-12-05 21:12           ` Borislav Petkov
2012-12-05 21:41             ` Alan Cox
2012-12-05 21:46               ` Borislav Petkov
2012-12-05 21:39           ` Alan Cox
2012-12-05 21:38       ` Andrew Morton
2012-12-05 21:50         ` Borislav Petkov
2012-12-07 16:52         ` Andreas Mohr
2012-12-07 17:44           ` Borislav Petkov
2012-12-08  7:36             ` Andreas Mohr
2012-12-08 10:52               ` Borislav Petkov
2012-12-08 23:04                 ` Alan Cox
2012-12-05 16:39     ` Andreas Mohr
2012-12-05 16:44       ` Borislav Petkov
2012-12-05 17:09         ` Andreas Mohr
2012-12-05 17:34           ` Borislav Petkov
2012-12-05 23:38     ` Rafael J. Wysocki
2012-12-05 23:35       ` Borislav Petkov
2012-12-06 14:04       ` Alan Cox
2012-12-06 20:56         ` Rafael J. Wysocki
2012-12-06 20:59           ` Borislav Petkov
2012-12-06 21:21             ` Rafael J. Wysocki
2012-12-06 21:20               ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121205070901.GA12123@rhlx01.hs-esslingen.de \
    --to=andi@lisas.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).