public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: Dave Jones <davej@redhat.com>,
	"Robert P. J. Day" <rpjday@mindspring.com>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: my handy-dandy, "coding style" script
Date: Wed, 20 Dec 2006 17:42:54 -0500	[thread overview]
Message-ID: <4589BC6E.7040209@tmr.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0612192125460.20733@yvahk01.tjqt.qr>

Jan Engelhardt wrote:
>>>>  just for fun, i threw the following together to peruse the tree (or
>>>> any subdirectory) and look for stuff that violates the CodingStyle
>>>> guide.  clearly, it's far from complete and very ad hoc, but it's
>>>> amusing.  extra searches happily accepted.
>>> I had a bunch of similar greps that I've recently been half-assedly
>>> putting together into a single script too.
>>> See http://www.codemonkey.org.uk/projects/findbugs/
>> I don't know if anyone cares about them anymore, since I think gcc
>> grew some smarts in the area recently, but there are a lot of lines of
>> code matching "static int.*= *0;" and equivalents in the driver tree.
> 
> I'd really like to see the C compiler being enhanced to detect
> "stupid casts", i.e. those, which when removed, do not change (a) the outcome
> (b) the compiler warnings/error output.

Bearing in mind that some casts may have been put in when struct members 
had other values, may be needed on some hardware but not others, etc. 
Cleanups are good, but may not be as obvious as they appear.

Not that there's a lack of places to remove visual cruft, but perhaps 
someone could look at casts and ask if each hides a real type mismatch.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

  parent reply	other threads:[~2006-12-20 22:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-19 15:46 my handy-dandy, "coding style" script Robert P. J. Day
2006-12-19 16:41 ` Dave Jones
2006-12-19 17:42   ` Bob Copeland
2006-12-19 20:27     ` Jan Engelhardt
2006-12-19 21:24       ` David Rientjes
2006-12-19 22:01         ` Jan Engelhardt
2006-12-19 23:09           ` David Rientjes
2006-12-20 22:42       ` Bill Davidsen [this message]
2006-12-21 20:52         ` Jan Engelhardt
     [not found]           ` <1166741599.27218.7.camel@localhost>
2006-12-21 23:29             ` Jan Engelhardt
     [not found]               ` <1166744416.14803.1.camel@localhost>
2006-12-21 23:56                 ` Jan Engelhardt
2006-12-22  0:57               ` David Rientjes
2007-01-02  1:21       ` H. Peter Anvin

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=4589BC6E.7040209@tmr.com \
    --to=davidsen@tmr.com \
    --cc=davej@redhat.com \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpjday@mindspring.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