linux-stable/net/9p
Dominique Martinet cf7c33d332
9p: remove dead stores (variable set again without being read)
The 9p code for some reason used to initialize variables outside of the
declaration, e.g. instead of just initializing the variable like this:

int retval = 0

We would be doing this:

int retval;
retval = 0;

This is perfectly fine and the compiler will just optimize dead stores
anyway, but scan-build seems to think this is a problem and there are
many of these warnings making the output of scan-build full of such
warnings:
fs/9p/vfs_inode.c:916:2: warning: Value stored to 'retval' is never read [deadcode.DeadStores]
        retval = 0;
        ^        ~

I have no strong opinion here, but if we want to regularly run
scan-build we should fix these just to silence the messages.

I've confirmed these all are indeed ok to remove.

Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
2023-07-20 19:14:50 +00:00
..
Kconfig 9p: Remove INET dependency 2023-05-04 21:46:57 +01:00
Makefile 9p/trans_fd: split into dedicated module 2022-01-10 09:58:30 +09:00
client.c 9p: remove dead stores (variable set again without being read) 2023-07-20 19:14:50 +00:00
error.c 9p: fix a bunch of checkpatch warnings 2021-11-04 21:04:25 +09:00
mod.c net/p9: load default transports 2022-01-10 10:00:09 +09:00
protocol.c net/9p: add p9_msg_buf_size() 2022-10-05 07:05:41 +09:00
protocol.h net/9p: add p9_msg_buf_size() 2022-10-05 07:05:41 +09:00
trans_common.c 9p: fix file headers 2021-11-03 17:45:04 +09:00
trans_common.h 9p: fix a bunch of checkpatch warnings 2021-11-04 21:04:25 +09:00
trans_fd.c 9p-for-6.2-rc1 2022-12-23 11:39:18 -08:00
trans_rdma.c 9p/rdma: unmap receive dma buffer in rdma_request()/post_recv() 2023-02-24 13:42:28 +00:00
trans_virtio.c 9p: virtio: skip incrementing unused variable 2023-07-20 19:14:50 +00:00
trans_xen.c 9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition 2023-04-02 01:00:31 +00:00