All of lore.kernel.org
 help / color / mirror / Atom feed
From: toralf.foerster@gmx.de (Toralf Förster)
To: cocci@systeme.lip6.fr
Subject: [Cocci] Fwd: Re: sizeof (struct tYpO *) : it is just a typo or rather a bug ?
Date: Mon, 28 Jul 2014 19:21:27 +0200	[thread overview]
Message-ID: <53D68697.9030504@gmx.de> (raw)
In-Reply-To: <20140725112038.GA401@khazad-dum.debian.net>

Hi Dear cocci,

may I forward to you this email from the LKML, Henrique thinks, that that issue worth a coccinelle patch
:-D


-------- Original Message --------
Subject: Re: sizeof (struct tYpO *) : it is just a typo or rather a bug ?
Date: Fri, 25 Jul 2014 08:20:39 -0300
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Toralf F?rster <toralf.foerster@gmx.de>
CC: linux-ia64 at vger.kernel.org, ceph-devel at vger.kernel.org, Linux Kernel <linux-kernel@vger.kernel.org>

On Thu, 24 Jul 2014, Toralf F?rster wrote:
> Inspired by this "typo" fix 
> http://article.gmane.org/gmane.linux.kernel/1754640
> I grep'ed the current git tree of linus for similar issues.

I wonder if we couldn't use Coccinelle to do that?  I would say it would be
not as cool as deep grep magick, but Coccinelle is cool by definition and
therefore immune from any such comparisons :-)

> Nevertheless I was told, that gcc doesn't complain about such things due
> to eventually evaluating it to "sizeof(null)". I'm however curious if at
> least a warning should be emitted in such a case, or?

Well, it cannot become a real bug because the moment the code changes to
actually access/derreference such a typo, it will cause the compiler to
abort with an error.  If gcc will have to waste a measurable amount of time
to issue such a warning, it is not worth it.

OTOH, such typos could confuse someone reading the code into thinking
they're dealing with a different structure or something, and it _is_
incorrect code no matter how harmless, so it makes sense to fix all such
typos eventually.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

  reply	other threads:[~2014-07-28 17:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-24 18:20 sizeof (struct tYpO *) : it is just a typo or rather a bug ? Toralf Förster
2014-07-24 18:20 ` Toralf Förster
2014-07-24 18:33 ` Ilya Dryomov
2014-07-24 18:33   ` Ilya Dryomov
2014-07-24 18:33   ` Ilya Dryomov
2014-07-24 18:37   ` Toralf Förster
2014-07-24 18:37     ` Toralf Förster
2014-07-24 18:37     ` Toralf Förster
2014-07-25 11:20 ` Henrique de Moraes Holschuh
2014-07-25 11:20   ` Henrique de Moraes Holschuh
2014-07-25 11:20   ` Henrique de Moraes Holschuh
2014-07-28 17:21   ` Toralf Förster [this message]
2014-07-28 20:13     ` [Cocci] Fwd: " Julia Lawall
2014-07-28 20:41       ` Toralf Förster
2014-07-28 20:50         ` Julia Lawall
2014-07-28 21:20           ` Toralf Förster
2014-07-29  5:49             ` Julia Lawall

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=53D68697.9030504@gmx.de \
    --to=toralf.foerster@gmx.de \
    --cc=cocci@systeme.lip6.fr \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.