From: "Yury V. Umanets" <umka@namesys.com>
To: Jesper Juhl <juhl@dif.dk>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: eliminating gcc warning...
Date: Fri, 09 Jan 2004 18:08:06 +0300 [thread overview]
Message-ID: <1073660886.19099.7.camel@firefly> (raw)
In-Reply-To: <Pine.LNX.4.56.0401091539140.12106@jju_lnx.backbone.dif.dk>
On Fri, 2004-01-09 at 17:43, Jesper Juhl wrote:
> On Fri, 9 Jan 2004, Yury V. Umanets wrote:
>
> > Hello all,
> >
> > I'm trying to eliminate all gcc warnings, which can be obtained by means
> > of using -Wall and -W gcc keys, in linux-2.6.1. I decided, that this
> > should be done step-by-step. And now I have made a patch for scripts
> > directory. See attachment.
> >
> > If something wrong and someone is so kind to tell me about, I will be
> > very thankful.
> >
>
> I'm doing a similar thing, and there's been quite a lot of discussion
> about patches of this sort.
>
> You should read the threads with these titles that have been active for
> the last few days :
>
> "Suspected bug infilesystems (UFS,ADFS,BEFS,BFS,ReiserFS) related to sector_t being unsigned, advice requested"
> "[PATCH] mm/slab.c remove impossible <0 check - size_t is not signed - patch is against 2.6.1-rc1-mm2"
> "[PATCH] fs/fcntl.c - remove impossible <0 check in do_fcntl - arg is unsigned."
> "[PATCH][RFC] variable size and signedness issues in ldt.c - potential problem?"
> "Cleanup patches - comparison is always [true|false] + unsigned/signed compare, and similar issues"
>
Hello Jesper,
I have read you emails about UFS,ADFS,BEFS,BFS,ReiserFS, etc. earlier
and I want to support your efforts.
> A lot of good comments have been made by various people in those threads
> about what type of patches are wanted and what type of patches are not
> wanted. Also some comments on what kind of warnings not to bother with
> (and why) have been made.
Ok, I will read also other threads. Nevertheless I don't like warnings
at all, doing this my point was to try to find out if some warnings
point to possible bugs. I have found something already in
fs/smbfs/inode.c -- using SET_UID() with 16 bit values.
> May I suggest that we maybe work together on this instead of duplicating
> eachothers effort?
ok, what would be nice.
> If you think that cooperating on this is a good idea, then feel free to
> email me privately and let's talk about how to split the task between us.
ok, I will, thanks.
>
>
> -- Jesper Juhl
--
umka
prev parent reply other threads:[~2004-01-09 15:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-09 12:49 eliminating gcc warning Yury V. Umanets
2004-01-09 14:43 ` Jesper Juhl
2004-01-09 15:08 ` Yury V. Umanets [this message]
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=1073660886.19099.7.camel@firefly \
--to=umka@namesys.com \
--cc=juhl@dif.dk \
--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 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.