linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Adrian Bunk <bunk@stusta.de>
Cc: Daniel Walker <dwalker@mvista.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] sys_semctl gcc 4.1 warning fix
Date: Wed, 10 May 2006 13:18:13 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.58.0605101240190.20305@gandalf.stny.rr.com> (raw)
In-Reply-To: <20060510162404.GR3570@stusta.de>


On Wed, 10 May 2006, Adrian Bunk wrote:

>
> It seems you don't understand the problem at all:
>

Actually I do, altough I admit my reply was for more the general case with
pointers. And that I was using TAGS to jump around the function and didn't
notice that copy_semid_from_user was defined just above the function :-/
OK, it's getting late for me.

>
> First of all note that your example does not apply in this case:
>
> copy_semid_from_user() does _not_ initialize sembuf in all cases.

Yes, but the attribute could still remove the warning without adding more
instructions.  And the fact that the attribute is there, we can use it to
know that it was looked at and remind us that it's used.

OK, we could just have an attribute on the declaration of the variable
that keeps that warning turned off.  It also lets us know that someone
looked at that variable to make sure it is ok. And we can still undefine
the attribute definition with a make parameter if we want to recheck all
those warnings.

>
> And you do not understand where gcc's problem is:
>
> gcc does in fact see that setbuf is always initialized if
> copy_semid_from_user() returns 0.


>
> setbuf is only initialized in the (cmd == IPC_SET) case and later only
> used in the (cmd == IPC_SET) case. And cmd can't change between the two
> occurences.
>
> Therefore, gcc should in theory already have enough information to prove
> that sembuf is always initialized before it's used.
>

OK in theory, with this example it does have enough info.  But how much
info do you want gcc to hold while it's compiling?

To know that it's ok you need to know the following:

(what you've mentioned)
 setbuf is initialized
     cmd == IPC_SET
      and
     if copy_sem_from_user returns zero.

 setbuf isn't used unless cmd == IPC_SET

Now gcc will also need to know (which is there, but extra info for
compiling):

  setbuf->uid is updated in copy_sem_from_user and it returns zero.
  setbuf->out is updated in copy_sem_from_user and it returns zero.
  setbuf->mode is updated in copy_sem_from_user and it returns zero.

So it isn't enough to just know sembuf was updated, but you also need to
know what parts of the structure is initialized and used.  This example is
trivial, but what happens when you have structures with 100 elements, and
some with pointers to other elements.  Should gcc keep track of all that
too?

-- Steve



  reply	other threads:[~2006-05-10 17:19 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-10  2:56 [PATCH -mm] sys_semctl gcc 4.1 warning fix Daniel Walker
2006-05-10 10:34 ` Alan Cox
2006-05-10 14:31   ` Daniel Walker
2006-05-10 15:09     ` Alan Cox
2006-05-10 15:06       ` Daniel Walker
2006-05-10 15:24         ` Steven Rostedt
2006-05-10 16:24           ` Adrian Bunk
2006-05-10 17:18             ` Steven Rostedt [this message]
2006-05-10 17:45               ` Steven Rostedt
2006-05-10 18:27                 ` Stephen Hemminger
2006-05-10 19:07                   ` Serge Belyshev
2006-05-10 20:24                 ` Adrian Bunk
2006-05-10 20:35                   ` Steven Rostedt
2006-05-10 20:36                   ` Adrian Bunk
2006-05-10 20:53                     ` Steven Rostedt
2006-05-10 19:20             ` Steven Rostedt
2006-05-10 19:49               ` Daniel Walker
2006-05-10 20:44                 ` Steven Rostedt
2006-05-10 21:11                   ` Daniel Walker
2006-05-10 21:20                     ` Al Viro
2006-05-10 21:33                       ` Daniel Walker
2006-05-10 21:39                         ` Al Viro
2006-05-10 21:45                           ` Daniel Walker
2006-05-10 21:48                             ` Al Viro
2006-05-11  6:36                       ` Steven Rostedt
2006-05-10 15:39         ` Alan Cox
2006-05-10 15:38           ` Daniel Walker
2006-05-10 16:21             ` Al Viro
2006-05-10 16:37               ` Daniel Walker
2006-05-10 16:42                 ` Al Viro
2006-05-10 17:25                   ` Daniel Walker
2006-05-10 19:55                 ` Alistair John Strachan
2006-05-10 22:03               ` Andrew Morton
2006-05-10 22:10                 ` Al Viro
2006-05-10 22:31                   ` David S. Miller
2006-05-10 22:45                     ` Al Viro
2006-05-10 23:05                       ` Andrew Morton
2006-05-10 23:20                         ` Al Viro
2006-05-10 23:45                           ` Andrew Morton
2006-05-11  1:28                             ` Al Viro
2006-05-11  8:11                               ` Steven Rostedt
2006-05-11 10:07                                 ` [PATCH -mm] introduce a false positive macro Steven Rostedt
2006-05-11 20:40                             ` [PATCH -mm] sys_semctl gcc 4.1 warning fix Adrian Bunk
2006-05-11 21:14                               ` Al Viro
2006-05-10 23:06                     ` Roland Dreier
2006-05-10 22:30                 ` David S. Miller
2006-05-11  2:58                   ` Mike Galbraith

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=Pine.LNX.4.58.0605101240190.20305@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bunk@stusta.de \
    --cc=dwalker@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    /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).