On Wed, 12 Sep 2012, Hugh Dickins wrote:
> > that we can't fix it all up to use
> > uninitialized_var() so this is handled the proper way?
>
> I do prefer to avoid it when we can, some reasons given below.
>
It's easily silenced with __maybe_unused. I advocated for using that
attribute for unusued labels in mm/slab_common.c as well where we now do
things like
#ifdef CONFIG_DEBUG_SLAB
out:
#endif
repeatedly, but others felt this was better than simply doing
out: __maybe_unused
Not sure what your preferences are for just adding __maybe_unused to the
declaration.
> > If CONFIG_BUG exists, then we should support it, right?
>
> Up to a point, yes: we don't encourage switching it off ("Just say Y").
> I'm reluctant to add a notation just for this discouraged case, but how
> how about this patch - does it actually fix the warning you see, David?
>
>
> [PATCH mmotm] mm-mmapc-replace-find_vma_prepare-with-clearer-find_vma_links
> fix
>
> Strangely, I can no longer get an uninitialized variable warning out of
> copy_vma(), with or without the BUG() there; but David Rientjes gets it
> when he builds with CONFIG_BUG off, which is understandable.
>
> uninitialized_var() can be a useful tool, but I do prefer to avoid it:
> partly because it might hide future errors, partly because I misspell
> it, but mainly because the need for it comes and goes so mysteriously.
>
> Given David's preference for no warning, mine for no uninitialized_var,
> and Linus's for renaming BUG() to I_AM_A_MORON() to discourage its use
> in the first place: copy_vma() seems a prime candidate for returning
> failure to mremap instead of crashing the system.
>
> Signed-off-by: Hugh Dickins <hu...@google.com>
Tested-by: David Rientjes <rient...@google.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
