All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcin Slusarz <marcin.slusarz@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org,
	Ben Fennema <bfennema@falcon.csc.calpoly.edu>
Subject: Re: [PATCH 6/6] udf: fix sparse warnings (shadowing & mismatch between declaration and definition)
Date: Wed, 19 Dec 2007 19:35:14 +0100	[thread overview]
Message-ID: <20071219183511.GC18104@joi> (raw)
In-Reply-To: <20071217165017.GJ6979@atrey.karlin.mff.cuni.cz>

On Mon, Dec 17, 2007 at 05:50:17PM +0100, Jan Kara wrote:
> > fix warnings:
> > fs/udf/super.c:1320:24: warning: symbol 'bh' shadows an earlier one
> > fs/udf/super.c:1240:21: originally declared here
> > fs/udf/super.c:1583:4: warning: symbol 'i' shadows an earlier one
> > fs/udf/super.c:1418:6: originally declared here
> > fs/udf/super.c:1585:4: warning: symbol 'i' shadows an earlier one
> > fs/udf/super.c:1418:6: originally declared here
> > fs/udf/super.c:1658:4: warning: symbol 'i' shadows an earlier one
> > fs/udf/super.c:1648:6: originally declared here
> > fs/udf/super.c:1660:4: warning: symbol 'i' shadows an earlier one
> > fs/udf/super.c:1648:6: originally declared here
> > fs/udf/super.c:450:6: warning: symbol 'udf_write_super' was not declared. Should it be static?
> >
> > Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> > CC: Ben Fennema <bfennema@falcon.csc.calpoly.edu>
>   Thanks for the patch.  The 'bh' change is fine. The problems with 'i'
> should be solved differently I think. Those functions UDF_SB_FREE,
> UDF_SB_ALLOC_PARTMAPS should be functions and not macros. Please convert
> those to either inline functions if they are small or to regular
> functions if they are larger.  It won't be completely trivial because of
> the hackery e.g. in UDF_SB_ALLOC_BITMAP. It gets an argument meaning on
> which struct member something should be performed. But for example in
> the UDF_SB_ALLOC_BITMAP case you can simply make the function return the
> pointer to allocated and initialized space and the caller would assign
> it to a proper element of the superblock.
Ok, I'll try to do it.

> This would help the overall
> code quality of UDF (which is sadly quite poor).
If you have other suggestions how to clean up this code, let me know.
I'll see what I can do with them ;)

Marcin

  reply	other threads:[~2007-12-19 18:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-16  2:17 [PATCH 6/6] udf: fix sparse warnings (shadowing & mismatch between declaration and definition) Marcin Slusarz
2007-12-17 16:50 ` Jan Kara
2007-12-19 18:35   ` Marcin Slusarz [this message]
2007-12-20 12:51     ` Jan Kara
  -- strict thread matches above, loose matches on Subject: below --
2007-12-24  0:10 [PATCH 0/6] udf: improve code related to super_block, was: udf: convert super_block macros to functions marcin.slusarz
2007-12-24  0:10 ` [PATCH 6/6] udf: fix sparse warnings (shadowing & mismatch between declaration and definition) marcin.slusarz

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=20071219183511.GC18104@joi \
    --to=marcin.slusarz@gmail.com \
    --cc=bfennema@falcon.csc.calpoly.edu \
    --cc=jack@suse.cz \
    --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.