[PATCH] xfs: silence GCC warning

[PATCH] xfs: silence GCC warning

[Paul Bolle]

Building xfs_ioctl.o triggers this GCC warning:
    In file included from fs/xfs/xfs_linux.h:49:0,
                     from fs/xfs/xfs.h:27,
                     from fs/xfs/xfs_ioctl.c:18:
    fs/xfs/xfs_ioctl.c: In function ‘xfs_find_handle’:
    include/linux/file.h:37:7: warning: ‘f.file’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    fs/xfs/xfs_ioctl.c:73:13: note: ‘f.file’ was declared here

In this function 'f' and ('f.file') are only used for the
XFS_IOC_FD_TO_HANDLE command. It is clear that 'f.file' is always used
initialized, but there appears to be no easy way to give GCC enough
information to determine that. So let's silence this warning, using the
pattern Ingo Molnar recently suggested.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) Compile tested only.

1) I fear that the only way to give GCC the information it needs to do
the flow analysis correctly is to split xfs_find_handle() into three
separate functions, one for each command it handles, and add one or two
helper functions for the code common to all three functions. That seemed
a bit drastic. But perhaps we should try that.

 fs/xfs/xfs_ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index 8305f2a..5c98ce3 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -70,7 +70,7 @@ xfs_find_handle(
 	int			hsize;
 	xfs_handle_t		handle;
 	struct inode		*inode;
-	struct fd		f;
+	struct fd		f = { }; /* Avoid GCC warning */
 	struct path		path;
 	int			error;
 	struct xfs_inode	*ip;
-- 
1.7.11.7

Re: [PATCH] xfs: silence GCC warning

[Christoph Hellwig]

Looks good, Dave has actually sent it a tidbit earlier as part
of his series with fixes for 3.7-rc

Re: [PATCH] xfs: silence GCC warning

[Paul Bolle]

On Fri, 2012-11-02 at 09:07 -0400, Christoph Hellwig wrote:
> Looks good, Dave has actually sent it a tidbit earlier as part
> of his series with fixes for 3.7-rc

I see, thanks.


Paul Bolle